I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
We ran the Unified Extensions migration method on each CUI init on the
off-chance that we would need to turn off or reverse the migration for
some reason.
Now that 109 has rolled out successfully, we can make this a one-time
migration for anybody that isn't following each version (for example,
ESR channel users).
Differential Revision: https://phabricator.services.mozilla.com/D167584
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
This patch removes the use of the "unified extensions" pref and adjust
the existing tests. More clean-ups will be done in follow-ups, e.g. the
removal of `gUnifiedExtensions.isEnabled` and some test-only changes to
no longer create a new window in each test file.
Differential Revision: https://phabricator.services.mozilla.com/D166908
And make callers rely on that instead of allowInheritPrincipal when
creating lazy tabs.
Unlike allowInheritPrincipal, skipLoad sets the nodefaultsrc attribute.
This avoids a load instead of falling back to about:blank.
One consequence of that is that switching to a lazy about:blank tab will
not notify invoke listeners registered with addTabsProgressListener
(listeners registered with addProgressListener will still be invoked).
Thus test browser_open_in_lazy_tab.js needs to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D166012
Since macOS fullscreen can handle incoming fullscreen requests during a
fullscreen transition, it is no longer necessary to check for
visibilitychange events, which are also no longer fired during these
tests.
Differential Revision: https://phabricator.services.mozilla.com/D164247
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
The WebExtension overflow list is created lazily because the panel itself is lazy, and only gets
inserted the first time it is needed. Originally, I had written a separate function `#getWebExtList()`
to do the work of forcing the WebExtension overflow list to de-lazify, and then hold a reference
to it in #webExtList.
It turns out, that's a bit of a footgun. More than once, I've used #webExtList directly, forgetting
that the value might turn out to be `null` because the list hasn't delazified yet.
In order to smooth out that rough edge, this patch makes `#webExtList` a memoizing (evalutes once,
caches the return value for subsequent calls) getter so that anything that uses it doesn't have
to worry about the lazification. The reference member is now called #webExtListRef, and I've
added documentation about how it's probably best not to use it directly.
Differential Revision: https://phabricator.services.mozilla.com/D162585
Long ago, the menu panel in was a customizable area that users could drag things into.
That changed back around 2017 in bug 1354117 when the Photon redesign was built. The
menu panel become a static menu, but we also made it possible to permanently move things
to the overflow panel of the nav-bar.
It looks like we never updated the area type constant from referring to the old menu panel
though, so it's "TYPE_MENU_PANEL", and registering a node for it happens with
registerMenuPanel. This patch changes to constant to TYPE_PANEL and updates the registration
method to registerPanelNode.
I a check around the codebase as well as GitHub looking to see if there were any
system add-ons or experimental WebExtensions that rely on TYPE_MENU_PANEL / registerMenuPanel,
but I couldn't find any.
Differential Revision: https://phabricator.services.mozilla.com/D161078
This property, along with the CustomizableUI.isWebExtensionWidget, will make it possible
to distinguish WebExtension-provided widgets without sniffing CSS classes, which is what
we currently do.
In the event that the widget has been destroyed or hasn't yet been created, this will
fallback to looking for the `-browser-action` suffix on the ID. This is mainly for use during
migrations which happen early during CustomizableUI startup, when it's unlikely that the
extensions have finished initializing themselves and creating their widgets yet.
Differential Revision: https://phabricator.services.mozilla.com/D160802
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Depends on D160292
Differential Revision: https://phabricator.services.mozilla.com/D160293
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Differential Revision: https://phabricator.services.mozilla.com/D160293
When Unified Extensions is enabled, we want to make it so that any WebExtension browser_actions
overflow into the Unified Extensions panel instead of the default overflow panel.
Differential Revision: https://phabricator.services.mozilla.com/D160293
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
