Currently used mostly by Twitter and Facebook to allow them to specify which virtual quick navigation keys assistive technologies should not use when in those web applications, but instead pass them through to the browser. JAWS is currently the only known assistive technology making use of this feature.
This works in Chrome and the new Edge, but not in Firefox, because JAWS stopped using ISimpleDOM in Firefox, which no longer gave them access to this attribute.
This bug is to allow exposure of the non-standardized data-at-shortcutkeys attribute value via a same-named IAccessible2 and ATK Object Attribute.
Differential Revision: https://phabricator.services.mozilla.com/D86181
We fixed what I think is the lone instance of writing into the (empty)
header in `SetLength` because it was causing TSan violations, so we should
be clear to make this `const`. This change is not terribly effective on its
own (cf. the `const_cast` required to make this work at all), but in the
next patch, we can rig up `sEmptyTArrayHeader` to be surrounded with "guard
pages" and make rogue accesses off the array header a little more protected.
Differential Revision: https://phabricator.services.mozilla.com/D88657
nsTArray_Impl::Assign/operator= copying from another array cause code bloat by
using ReplaceElementsAtInternal without exploiting the knowledge that the whole
array is being replaced. Since for many instances of the class template, this
is the only ReplaceElementsAtInternal call being done, this unnecessary bloats
the generated code. Apart from that, it is suboptimal at runtime due to
unnecessary checks.
Furthermore, the implementation of ReplaceElementsAtInternal may unnecessarily
relocate the existing elements before destroying them if the storage needs to
be reallocated. While this could be optimized in ReplaceElementsAtInternal as
well, it is simpler to do so in the specialized AssignInternal that is now
introduced.
Differential Revision: https://phabricator.services.mozilla.com/D86723
This code was there to prevent stuff like bug 424377, but nowadays clone
documents are data documents to begin with, so they can't load scripts.
Differential Revision: https://phabricator.services.mozilla.com/D86948
This attribute will subsume the existing sameProcessAsFrameLoader attribute. It
works by specifying the BrowsingContextGroup which the initial BrowsingContext
in a <browser> should be created within.
Due to bug 1652144, all documents within the same BrowsingContextGroup with the
same remote type will be loaded in the same process, meaning that specifying
both "initialBrowsingContextGroupId" and "remoteType" will cause the initial
about:blank document to be loaded in a specific content process.
Differential Revision: https://phabricator.services.mozilla.com/D85650
I realized this was broken because feature policy was not accounting for
it (I fixed that in 79), but I _thought_ we weren't shipping
feature policy. It turns out we've been shipping it for a while (since 74),
so I'd rather remove support for it officially.
Differential Revision: https://phabricator.services.mozilla.com/D86191
This patch:
- Creates an anon-box pseudo-style for PrintedSheetFrame, in part so that it
can co-opt the styles that we formerly gave to page-frames in ua.css, to draw
the sheet of paper and the shadow in Print Preview.
- Adjusts nsCSSFrameConstructor to create a PrintedSheetFrame as the parent of
nsPageFrame (inserting between it and its nsPageSequenceFrame container, in
the frame tree).
- Fleshes out out a simple BuildDisplayList() implementation for
PrintedSheetFrame (taking the responsibility for "paper"-drawing from
nsPageFrame).
- Fleshes out a simple Reflow implementation for PrintedSheetFrame, just
placing the child page (assuming there's only one for now) at the origin.
- Adjusts nsPageFrame and nsPageSequenceFrame to account for the fact that
there's another layer between them now.
Note that PrintedSheetFrame needs to implement AppendDirectlyOwnedAnonBoxes()
(just as nsSimplePageSequence and nsPageFrame do), since it owns anonymous
nsPageFrame instances. This implementation only needs to append the first
child, as explained in the code-comment and in
https://bugzilla.mozilla.org/show_bug.cgi?id=1374761#c9 (and of course, for
now, PrintedSheetFrame only has one child at a time anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D83457
The mentioned array operations were implemented using SwapElements, which is a
rather generic and therefore complex method (in the sense of template
instantiation and code generation), which doesn't make use of the knowledge that
the target array is empty and does not have any allocated heap storage.
Similar to the introduction of MoveConstructNonAutoArray, a new method, MoveInit,
is introduced that uses this knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D84806
The move constructor of nsTArray_Impl (and therefore of nsTArray) was
implemented using SwapElements, which is a rather generic and therefore
complex method (in the sense of template instantiation and code generation),
which doesn't make use of the knowledge that the target array does not have
inline storage and is empty with 0 capacity. Therefore, a new specialized method,
MoveConstructNonAutoArray, is introduced that does use this knowledge. This
adds another method to maintain, but given that the move constructor is a
frequently used operation that is expected to have a small compile-time and
run-time cost (potentially used implicitly), this seems like a reasonable
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D84804
The mentioned array operations were implemented using SwapElements, which is a
rather generic and therefore complex method (in the sense of template
instantiation and code generation), which doesn't make use of the knowledge that
the target array is empty and does not have any allocated heap storage.
Similar to the introduction of MoveConstructNonAutoArray, a new method, MoveInit,
is introduced that uses this knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D84806
The move constructor of nsTArray_Impl (and therefore of nsTArray) was
implemented using SwapElements, which is a rather generic and therefore
complex method (in the sense of template instantiation and code generation),
which doesn't make use of the knowledge that the target array does not have
inline storage and is empty with 0 capacity. Therefore, a new specialized method,
MoveConstructNonAutoArray, is introduced that does use this knowledge. This
adds another method to maintain, but given that the move constructor is a
frequently used operation that is expected to have a small compile-time and
run-time cost (potentially used implicitly), this seems like a reasonable
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D84804
Add an event handler `onactivated/ondeactivated` and a readonly attribute `isActive` on the media control webidl interface, and they can be used in testing and the future plan of supporting media hub.
Differential Revision: https://phabricator.services.mozilla.com/D85229
We do not expose it nor ever style it. Just use the parent style all the
time. This avoids problematic style resolution calls during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D84358
Marco Zehe
Jeff Walden
Sylvestre Ledru
Nathan Froyd
Razvan Maries
Emilio Cobos Álvarez
Narcis Beleuzu
Masatoshi Kimura
Simon Giesecke
Chris Fronk
alwu
Zeke Medley
Mihai Alexandru Michis
Nika Layzell
Daniel Holbert
Noemi Erli
Alexander Surkov
Sebastian Streich
Tim Nguyen
Honza Bambas