This introduces `mainview-with-header` attribute for panels that their
mainview should have a header (no matter where they appear); and
`has-custom-header` for panels that their panelview (not necessarily a
mainview) has a custom design for a header, one that headerText setter
can't anticipate in advance (due to UX needs that may arise).
If one of these attributes are set on the panel, this signals headerText
that the panelview's header should NOT be removed and that the markup
should be respected.
Differential Revision: https://phabricator.services.mozilla.com/D196671
On Linux it doesn't look as bad without this, but on macOS it's very
noticeable.
This ensures that items are properly centered.
The flex display / alignment of the link isn't needed (it only has text
anyways).
Differential Revision: https://phabricator.services.mozilla.com/D193784
Customize mode was already using display: flex, so the migration caused
some interesting interactions.
In particular -moz-box-flex: 1 rules had no effect at all, so remove
them (same for the flex="" attribute).
Un-flex items in the overflow menu so that they don't spread too much.
Use flex: 1 in the customization-content-container to reset flex-shrink
to 1 (XUL flex didn't allow shrinking by default, so xul.css has
flex-shrink: 0).
Differential Revision: https://phabricator.services.mozilla.com/D172144
While at it remove useless display declaration too.
vbox was setting -moz-box-orient: vertical, but that had no effect
because it had display: flex explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D172145
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
