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
I noticed some missing context menu style when loading the context menu
from our own viewcache, which explains the difference between primary
and secondary button click. Not sure ecavtly what was missing as the
styles are all over the place.
The menu item actually works, the actions are called and for
checkbox-like menu items, the `checked` attribute is correctly set in
the "HTML". Also it looked like sub-menus weren't affected (e.g. Tree
Style Tab didn't have any issue).
While investigating, I also noticed that most (if not all) `menupopup`
elements are declared in the main popupset, so I tried to move the
unified extensions context menu to this main popupset and lazy-load the
l10n strings (similar to the toolbar context menu [1]).
That fixed the bug.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1609556
Differential Revision: https://phabricator.services.mozilla.com/D153330
This patch allows to open the context menu on (primary) button click,
and that also works with keyboard navigation.
Depends on D152755
Differential Revision: https://phabricator.services.mozilla.com/D152853
