Many WPT reftests compare Ahem glyphs (squares) with a reference that uses simple shapes
such as a <div> with a solid background that is expected to have the exact same size.
If antialiasing is applied to the Ahem font, such tests will often fail because of
faint antialiasing pixels at the edges of the square glyphs, even though the test is
"passing" in terms of what it actually aims to check.
Rather than annotate all such tests as "fuzzy", Gecko has an option to disable antialiasing
for the Ahem font, despite it being enabled for font rendering in general, and we use this
when running the WPT reftests. However, this depends on the font-family name being exactly
"Ahem".
Therefore, in the tests which load Ahem via @font-face and override some descriptors,
we still want to use "Ahem" as the resulting family name (shadowing the standard Ahem,
if it is locally installed) so that the non-antialiased rendering will be used.
(In the case of metrics-override-normal-keyword, there are multiple "custom" versions
of Ahem loaded by the testcase, so we instead take the approach of also loading it with
a modified family name in the reference; then both testcase and reference will get
the default antialiased font rendering rather than special "Ahem" treatment.)
Differential Revision: https://phabricator.services.mozilla.com/D109290
I kept a few having some overrides. But they may be irrelevant.
And I kept some eslint files for all folder that aren't matching the pattern matching "**/test*/**/browser*/".
Ideally we would rename these folder to match.
Last but not least, I identified one case where we were using mochitest file for xpcshell tests!
Differential Revision: https://phabricator.services.mozilla.com/D109481
Without this change, profiles that participated in the rollout that turned on WebRender for qualified Intel devices will continue to due extraneous work every start up to set the relevant preference, even though nothing is reading it. The information that the profile is active in the rollout also shows up in telemetry and about:support data unnecessarily.
Differential Revision: https://phabricator.services.mozilla.com/D108831
This will allow higher sample rate decoding when the platform supports it, and
will offer a similar error in cases where the platform does not.
Depends on D109380
Differential Revision: https://phabricator.services.mozilla.com/D109381
Launching new profiles from the ProfileManager is done with the
-no-remote command-line argument; this decision is silently hardcoded,
hence confusing.
Differential Revision: https://phabricator.services.mozilla.com/D106684
This is macOS only and behind the prefs widget.macos.native-context-menus and
browser.proton.contextmenus.enabled .
The big design question here is: Where do we put the fork in the road? How much
should the existing non-native popup management machinery know about the state
of the native menu? Which parts of the non-native state should a) reflect the
true native state, b) enter a special "handled natively" state, or c) lie?
This patch picks the following approach:
- The nsMenuPopupFrame of the root menupopup knows about the native menu; it
keeps it alive in its new mNativeMenu field.
- If the context menu has submenus, i.e. nested <menupopup> elements, the
nsMenuPopupFrames for those nested menupopups do not know anything about the
native menu.
- The mPopupState of natively-handled nsMenuPopupFrames is ePopupClosed.
- XULPopupElement::GetState, which queries the frame's mPopupState, also
returns "closed". This might cause problems in the future.
- The XUL popup manager's mPopups "menu chain" does not know about any open
native menus.
- The rollup widget also does not know about the native popup.
I've chosen to use ePopupClosed for native menus for the following reasons:
1. While mirroring / updating the state for the root menu would be doable
without too much trouble, it would be much more annoying to do the same for
nested menupopups of submenus. So if submenus will be ePopupClosed, it's
consistent for the root menu to also be ePopupClosed.
2. nsXULPopupManager has assertions (for example in MayShowPopup) that make
sure that the menu popup frame's mPopupState is consistent with the XUL
popup manager's mPopups menu chain. Keeping the two both "closed" is the
easiest way to achieve consistency.
Unless there are grave concerns with this approach, I suggest we go with it for
now and see what trouble arises.
Differential Revision: https://phabricator.services.mozilla.com/D109183
This will be useful for native context menus: We can call OnOpen() before we
ask the OS to open the menu. This way, popupshowing handlers can prevent the
menu from opening.
I was also planning to use this to call OnOpen during menuNeedsUpdate, which is
where the Apple docs say we should do our menu modifications. However, doing so
has some other effects so I will hold off on making that change.
This patch also clarifies our inability to interfere with menu opening, which
clashes a little bit with the cross-platform expectations around popupshowing
events, but should hopefully not make a difference in practice.
Differential Revision: https://phabricator.services.mozilla.com/D108721
