Previously, text children were excluded from the a11y tree, so they weren't considered when computing name from subtree.
Differential Revision: https://phabricator.services.mozilla.com/D111029
Previously, when determining the modifier, the code used the uncomposed document, which will be null for an element inside shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D111033
There are two parts to this. The first part is simply fixing the
issue, which was an oversight. The second part is rejecting with a
JavaScript `Error`, which provides a nicely formatted stack in the
browser console, easing debugging.
Differential Revision: https://phabricator.services.mozilla.com/D111223
This calculation was previously required, but is now only used by
the methods that set up a compositor surface. The early out check
for invalid prim_rect is covered by the clip chain rect test below.
This removes a per-prim map operation from a hot part of the frame
building visibility pass.
Differential Revision: https://phabricator.services.mozilla.com/D111224
This test no longer passes with proton enabled by default, since the
deck would've been created already during startup.
Depends on D111309
Differential Revision: https://phabricator.services.mozilla.com/D111310
This change prepares the font preview generation for the display within the Network Monitor's Response view.
In there, the preview is meant to contain all the letters of the Latin alphabet in upper and lower case plus the numbers from 0 to 9 and different characters in other alphabets.
As those are too long to be displayed in a single line, they will be split into several ones.
For this to work, the getFontPreviewData() method now splits the given preview text at new-line characters into several lines.
This also means that for the existing single-line preview texts within the Inspector there is no change.
Differential Revision: https://phabricator.services.mozilla.com/D110167
This changes the test a bit. It doesn't test BroadcastChannel's postMessage anymore, but receiving the message.
I can't see how postMessage could be tested, since given the new setup, no one should have access to it anymore.
This is functionally now very similar to another test I wrote recently, but I think it is fine to keep this too.
Differential Revision: https://phabricator.services.mozilla.com/D109539
Now that nsMenuPopupFrame considers itself open while the native menu is shown,
it may try to open its non-native widget if layout happens to run while the
native menu is shown.
This check prevents that.
Differential Revision: https://phabricator.services.mozilla.com/D111326
gcc doesn't support using -mrecip=none universally and it's a
pain to keep track of where it's supported so just avoid using
-ffast-math altogether.
Differential Revision: https://phabricator.services.mozilla.com/D111304
This builds on D111205 by factoring out some initialization into a new
`initPageActionsTest()` in head.js. I'll need to use it in
browser_PageActions_newWindow.js too (bug 1703389).
Pre-Proton, there are 4 page action context menu items:
* Add to Address Bar
* Remove from Address Bar
* Manage Extension
* Remove Extension
Regardless of Proton, there are two context menus, one for buttons in the urlbar
and one for items in the page action panel. They're actually the same menu of
course.
This test currently checks each menu item in both context menus for a
non-built-in action except for the Remove Extension menu item. In Proton, we
don't need to check Add or Remove, so I modified the test to skip them. I also
added a check for the Remove Extension menu item. The test now must actually
create an extension with a page action to test the context menu because in
Proton only actions with extension IDs get the context menu (bug 1700364). Since
the test is creating an extension anyway, testing the Remove Extension menu item
isn't too hard.
Depends on D111205
Differential Revision: https://phabricator.services.mozilla.com/D111222
Flip javascript.options.wasm_simd to true for beta and release.
This patch leaves the flag as true on nightly and otherwise false, for arm64,
since arm64 code landing is imminent. But in truth simd is not even compiled
in for arm64 at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D111285