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
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
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
There was only a min-height: 0 missing. I also cleaned-up a bit because
flex: 1 is the same as flex: 1 1 auto, and flex attribute (which only
sets -moz-box-flex) is not doing anything because it was inside flex
layout (so legacy properties aren't looked at).
Differential Revision: https://phabricator.services.mozilla.com/D160094
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
The virtual click event is also removed. It seems this event is only used to check whether this was a key or mouse event in PanelMultiView.jsm
This also removes support for pressing the enter key to trigger these toolbarbuttons on Mac which shouldn't be happening anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149285
The virtual click event is also removed. It seems this event is only used to check whether this was a key or mouse event in PanelMultiView.jsm
This also removes support for pressing the enter key to trigger these toolbarbuttons on Mac which shouldn't be happening anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149285
The virtual click event is also removed. It seems this event is only used to check whether this was a key or mouse event in PanelMultiView.jsm
This also removes support for pressing the enter key to trigger these toolbarbuttons on Mac which shouldn't be happening anyway.
Differential Revision: https://phabricator.services.mozilla.com/D149285
Instead of copying from label-* attributes, set data-l10n-id for each
notification
Also, stop using attributes for checking if the notification is supported.
Differential Revision: https://phabricator.services.mozilla.com/D129270
