This will force the panel to close when we click an item in the context
menu, without having to handle each menu item separately.
Differential Revision: https://phabricator.services.mozilla.com/D162424
Similar to the Manage/Remove/Report actions in the (context) menu, we
close the unified extensions panel when clicking "Pin to toolbar". This
will also prevent the panel to be empty when there is only one extension
listed and we decide to pin it to the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D162414
This area doesn't have any special rules applied yet, nor can it have items moved to
it except programmatically. All of that will come later, including tests.
Differential Revision: https://phabricator.services.mozilla.com/D161079
This patch adds a specific path for getting the localized text for the addon
install prompt for SitePermissionsAddon.
As the message that we want isn't very generic, each gated permission will have
its own localized addon prompt message.
Differential Revision: https://phabricator.services.mozilla.com/D160452
This patch adds a specific path for getting the localized text for the addon
install prompt for SitePermissionsAddon.
As the message that we want isn't very generic, each gated permission will have
its own localized addon prompt message.
Differential Revision: https://phabricator.services.mozilla.com/D160452
This is to fix Fluent errors being thrown because the Unified Extension panel
isn't created dynamically anymore, and is part of the DOM (in a <template>).
Differential Revision: https://phabricator.services.mozilla.com/D161081
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
This patch also adjusts some `min-width` rules like it was done for the
downloads button. It should work with either buttons OR both, which is
going to happen since the unified extensions button will be most likely
always visible in the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D154360
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
When these panels had arrows, I guess the bottomcenter topleft alignment
made sense so that you could precisely align the arrow, but that's not
what we do now.
Don't use bottomcenter / leftcenter / rightcenter, since we really want
the sides to align.
This shouldn't change behavior on any platform except Linux + Wayland,
where the alignment looks good now in the case of bug 1784876.
Differential Revision: https://phabricator.services.mozilla.com/D156099
