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
To align with other browsers, the user gesture requirement has
been removed and there is now an optional first argument which
can be used to provide a windowId.
Differential Revision: https://phabricator.services.mozilla.com/D139796
We want to encourage extension developers to use `browser_specific_settings` instead of `applications`,
which will be unsupported in Manifest Version 3+. This patch prepares the introduction of a new warning
(that is usually converted into an error in the test environment).
Differential Revision: https://phabricator.services.mozilla.com/D160059
To align with other browsers, the user gesture requirement has
been removed and there is now an optional first argument which
can be used to provide a windowId.
Differential Revision: https://phabricator.services.mozilla.com/D139796
This migrate gDevTools.showToolbox, but also the Toolbox now receives a commands right away,
and no longer need to create commands out of the descriptor front.
I'm removing browser_two_tabs as it is focusing on testing Tab Descriptors (RootFront.listTabs+getTab)
and Tab targets (TabDescriptor.getTarget).
Using getTarget on descriptor is legacy codepath for a while now.
We should now rather cover commands instead of these low level RDP methods.
Differential Revision: https://phabricator.services.mozilla.com/D157796
This migrate gDevTools.showToolbox, but also the Toolbox now receives a commands right away,
and no longer need to create commands out of the descriptor front.
I'm removing browser_two_tabs as it is focusing on testing Tab Descriptors (RootFront.listTabs+getTab)
and Tab targets (TabDescriptor.getTarget).
Using getTarget on descriptor is legacy codepath for a while now.
We should now rather cover commands instead of these low level RDP methods.
Differential Revision: https://phabricator.services.mozilla.com/D157796
In addition to adding messages for origin controls, this patch slightly
changes the UI to account for long l10n strings. As a result, the name
of the extension is no longer truncated with CSS (ellipsis). This isn't
a big problem as these names cannot exceed 45 characters (max 2 lines of
text). This allows us to better handle long permission messages and
(Windows) scrollbars. UX is OK with that at the moment.
We also retain the "default" height of the message below the name of an
extension (using the `min-height` property) to avoid flickering as per
UX guidelines.
Differential Revision: https://phabricator.services.mozilla.com/D156808
In addition to adding messages for origin controls, this patch slightly
changes the UI to account for long l10n strings. As a result, the name
of the extension is no longer truncated with CSS (ellipsis). This isn't
a big problem as these names cannot exceed 45 characters (max 2 lines of
text). This allows us to better handle long permission messages and
(Windows) scrollbars. UX is OK with that at the moment.
We also retain the "default" height of the message below the name of an
extension (using the `min-height` property) to avoid flickering as per
UX guidelines.
Differential Revision: https://phabricator.services.mozilla.com/D156808
This is the last fix needed for this.
The issue is that command events now are triggered by synthetic click
events (which was not the case before pretty much by chance, a side
effect of how these events were implemented).
If we open a panel by a command event triggered by the synthetic click
event, rather than the real keypress event, we end up not detecting that
it is really a keyboard activation, and not focusing the first navigable
element in the panel for example, which is unfortunate.
This was caught by browser_toolbarButtonKeyPress.js.
We could keep the old behavior of not triggering commands from
dispatchEvent()-ed clicks, but honestly that's kind of bizarre.
Differential Revision: https://phabricator.services.mozilla.com/D157596
