I was unable to get gnome searching working at all on my machine (perhaps it's broken on Ubuntu?), thus I was unable to verify this fix myself -- but it seems pretty straightforward and safe to take.
Differential Revision: https://phabricator.services.mozilla.com/D164902
This will mean that we drain direct tasks immediately after executing
things like native OS messages through OnProcessNextEvent, and also that
we drain direct messages immediately when entering a nested event loop,
rather than after processing the first runnable in that nested event
loop. This should make the behaviour a bit more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D164839
This adds the <moz-support-link> custom element as well as stories and
tests for this reusable component. The purpose of this component is to
replace individual implementations of the "Learn more" links present
in Firefox, specifically in about:preferences and about:addons.
See Bug 1801927 for an instance of using this component to refactor
the "Learn more" links in about:preferences#general.
Differential Revision: https://phabricator.services.mozilla.com/D164131
Just disable in the build config for now. It is unlikely that any issues will
come up since this is disabled in release but just in case this will allow us
to re-enable it quickly.
Differential Revision: https://phabricator.services.mozilla.com/D164565
The data race is happening, because `nsHttpTransaction::ParseLineSegment`
can be called before `nsHttpTransaction::AsyncRead`. Initializing it in
`nsHttpTransaction::Init` removes the race condition.
Should fix most early hint intermittent:
* Bug 1744028
* Bug 1746324
* Bug 1760124
* Bug 1775763
* Bug 1803884
Differential Revision: https://phabricator.services.mozilla.com/D164321
Just disable in the build config for now. It is unlikely that any issues will
come up since this is disabled in release but just in case this will allow us
to re-enable it quickly.
Differential Revision: https://phabricator.services.mozilla.com/D164565
If the UA sheet gets parsed with the pref off, and then the pref gets
flipped on, we don't re-parse the UA sheet (nor we want to).
Enable the property in UA sheets unconditionally so that the test passes
even when the browser was started-up with the container queries pref
off.
Differential Revision: https://phabricator.services.mozilla.com/D164823
Just disable in the build config for now. It is unlikely that any issues will
come up since this is disabled in release but just in case this will allow us
to re-enable it quickly.
Differential Revision: https://phabricator.services.mozilla.com/D164565
This makes it possible to use the resolve all configs option and set up
different first party modules for different directories.
The downside is that configuration options (e.g. profile = black) have to
be repeated in every .isort.cfg file, because isort never merges configuration
files.
Differential Revision: https://phabricator.services.mozilla.com/D163567
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
I decided to split this up from bug 1805414 because it's only
tangentially related to the removal of nsMenuFrame.
We have this sizetopopup attribute and behavior that allows menulists to
be sized to the contents of the popup. The popup also expands to the
menulist rect.
This means that layout is by somewhat cyclic and we need to go out of
our way to support it. However, I think we only care about the first
behavior. We don't have many non-intrinsically-sized menulists, and
if we need we can use HTML <select> instead, which does have that
behavior.
Simplify the setup to make sizetopopup only apply to menulists (we don't
have non-menulist usage anyways), and only work in the "popup depends on
the menulist" direction, not the other way around.
This will allow making the popup a regular out-of-flow element. The
change to test_menulist_paging is not needed (I restored the behavior of
eagerly layout menulists, to fix the <select> popup, but I'd like to fix
that eventually, so I'd rather leave them in, they're harmless).
Differential Revision: https://phabricator.services.mozilla.com/D164693
`.footer` is no longer used on extraClasses, so I got rid of that.
I simplified the `.entry` bits because they were unnecessarily
verbose. Honestly I think we may be able to remove the getter/setter
for `options` entirely, but I got bored of trying to modernize things...
PlacesPanelMenuView was introduced in bug 963095 and then replaced
as part of Photon (with PlacesPanelview) and then I removed the only
callsite (that was already behind a pref) in bug 1354117, so that was
just dead code, AFAICT, so I removed it.
Differential Revision: https://phabricator.services.mozilla.com/D164757
Only the bookmarks menu button is doing this peculiar re-using of
options.
I tried various fixes: keeping the inheritance but replacing only the
rootElt/viewElt (and using Object.assign to clone the options so modifications
don't 'transmit' to the ancestor menus) but it was messy and net code increase
for a pretty crufty UI surface. I also wasn't sure if that would end up
negatively influencing (now or in the future) e.g. menus shown from the main
bookmarks toolbar view (which would show up as a 'parent' view for the menus
we open from there), and thought that reusing the options was likely to cause
further confusion in future as well, should we add more, uh, options, to them.
So in the end I stuck with Keeping It Simple - I just repeat the one-off
repeating entry class. I'm not even sure how needed this is - in particular,
I wonder why we don't need it for other submenus for 'real' bookmark folders!
But I didn't investigate this too much. If you're sure that we can get rid of
some more of it, happy to do that in a followup.
Note that the addition of _init() was not ultimmately needed to fix this bug
(I think), but it brought the initialization sequence and when we set
`_placesView` more in line with what we did before and what I already did for
`PlacesToolbar`, so that seemed like a good thing to avoid further/other issues.
Differential Revision: https://phabricator.services.mozilla.com/D164756
