We have a function, OverflowableToolbar.findOverflowedInsertionPoints, whose job it is to compute
the right insertion point for a widget if the widget is being inserted into an overflowable
toolbar.
That function failed to account for the possibility that the widget was a browser action, and
would return the #defaultList instead of the #webExtList if the item was overflowing. This
patch checks the ID of the widget first, and then supplies the correct list.
Differential Revision: https://phabricator.services.mozilla.com/D162586
The WebExtension overflow list is created lazily because the panel itself is lazy, and only gets
inserted the first time it is needed. Originally, I had written a separate function `#getWebExtList()`
to do the work of forcing the WebExtension overflow list to de-lazify, and then hold a reference
to it in #webExtList.
It turns out, that's a bit of a footgun. More than once, I've used #webExtList directly, forgetting
that the value might turn out to be `null` because the list hasn't delazified yet.
In order to smooth out that rough edge, this patch makes `#webExtList` a memoizing (evalutes once,
caches the return value for subsequent calls) getter so that anything that uses it doesn't have
to worry about the lazification. The reference member is now called #webExtListRef, and I've
added documentation about how it's probably best not to use it directly.
Differential Revision: https://phabricator.services.mozilla.com/D162585
We have some internal bookkeeping within OverflowableToolbar to remember the state of things that
have overflowed, like how wide the window needs to be before they can be moved back, etc. When an
item is removed from an overflowable toolbar while overflowed, we update that internal bookkeeping
so that OverflowableToolbar doesn't accidentally try to move those items back into the toolbar
when the window becomes wide enough again.
We've added a new overflow list for extension buttons, but we weren't updating our internal accounting
when items had been overflowed into that list. This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D162434
Even if Unified Extensions is enabled, it is expected that each registered area
will have a placements array set in gPlacements. When resetting, that's normally
re-created in restoreStateForArea, but we were skipping that call for AREA_ADDONS,
and then manually setting the placements array - but only if Unified Extensions
was enabled.
This change makes it so that we always set it when resetting.
Differential Revision: https://phabricator.services.mozilla.com/D162306
This isn't a migration just yet. I'm following the same technique that we seemed to follow
when we first introduced the original overflow menu (see bug 1354117) - I'm going to add
a function to do the migration here, with a mechanism for (somewhat) reversing the
migration if the preference gets flipped back to false at some point.
There is no expectation that this preference will be flipped back to false - it's more of
a safety mechanism. Once we're confident that the routine in the function properly moves
items to right places, we can convert it to a proper migration so that it only runs
once on startup for folks who upgrade.
Differential Revision: https://phabricator.services.mozilla.com/D161839
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
This property, along with the CustomizableUI.isWebExtensionWidget, will make it possible
to distinguish WebExtension-provided widgets without sniffing CSS classes, which is what
we currently do.
In the event that the widget has been destroyed or hasn't yet been created, this will
fallback to looking for the `-browser-action` suffix on the ID. This is mainly for use during
migrations which happen early during CustomizableUI startup, when it's unlikely that the
extensions have finished initializing themselves and creating their widgets yet.
Differential Revision: https://phabricator.services.mozilla.com/D160802
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
This patch makes it so that OverflowableToolbar.#moveItemsBackToTheirOrigin
is not coupled to the existing overflowed item list, and instead takes
advantage of the insert-order provided when calling #overflowedInfo.entries()
and queries the DOM for the overflowed item IDs directly.
A later patch in this series is going to conditionally move overflowed
items into different panels based on whether or not they're provided
by WebExtensions, and so this change means that #moveItemsBackToTheirOrigin
is not going to care which panel the overflowed items are in, it should
behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D160292
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
This patch makes it so that OverflowableToolbar.#moveItemsBackToTheirOrigin
is not coupled to the existing overflowed item list, and instead takes
advantage of the insert-order provided when calling #overflowedInfo.entries()
and queries the DOM for the overflowed item IDs directly.
A later patch in this series is going to conditionally move overflowed
items into different panels based on whether or not they're provided
by WebExtensions, and so this change means that #moveItemsBackToTheirOrigin
is not going to care which panel the overflowed items are in, it should
behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D160292
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
This patch makes it so that OverflowableToolbar.#moveItemsBackToTheirOrigin
is not coupled to the existing overflowed item list, and instead takes
advantage of the insert-order provided when calling #overflowedInfo.entries()
and queries the DOM for the overflowed item IDs directly.
A later patch in this series is going to conditionally move overflowed
items into different panels based on whether or not they're provided
by WebExtensions, and so this change means that #moveItemsBackToTheirOrigin
is not going to care which panel the overflowed items are in, it should
behave the same.
Differential Revision: https://phabricator.services.mozilla.com/D160292
This patch does not aim to change the behaviour of OverflowableToolbar
at all. Instead, it:
1. Migrates off of old-school prototype class to a modern ES6 class
2. Uses actual private members and methods rather than underscore
pseudo-private members and methods.
3. Tries to group the methods of OverflowableToolbar into groups like
public methods, private methods, private event handlers, CUI widget
listener methods and finally XPCOM interface implementations.
4. Tries to add JSDoc-style documentation where possible.
Differential Revision: https://phabricator.services.mozilla.com/D160106
The bug fix is in the line:
this._collapsed.set(child.id, targetContentWidth);
we used to set this._target.clientWidth, which doesn't account for the
potentially-overflowing children of this._target. Propagate that from
the _checkOverflow function instead.
I'm not sure what's the best way to write a test for this. Any ideas?
Differential Revision: https://phabricator.services.mozilla.com/D159773
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
This was used to prevent reflows due to popuppositioned events during
view transitions.
The previous patch should've prevented the popuppositioned events to
begin with, plus we no longer use arrows that need positioning etc,
which means we shouldn't be triggering the reflows anyways.
Since this is the only consumer of autoPosition = true/false, we can
remove the code supporting it. It's a bit bogus as per the commit
message of the previous patch and, while fixable, it doesn't seem worth
fixing if we can just get rid of it.
Depends on D159936
Differential Revision: https://phabricator.services.mozilla.com/D159937
getOuterScreenRect doesn't flush layout, so not flushing here should be
fine.
We only care about the CSS width / height, not about the screen
positioning, so this is more accurate.
The flickering in comment 8 (the hover effect in the "restore previous
session" button) happens because the following set of events:
* We try to lock the size of the panel.
* The size returned by getOuterScreenRect() is fractionally different
to the actual size.
* We get to [1], realize we've changed size (even though fractionally),
set the origin at 0, 0, and then call SetPopupPosition to fix that
up.
* But we've disabled autopositioning[1], so the layout position of the
panel remains at 0, 0.
This prevents the flickering by using the actual layout size
(getBoundsWithoutFlushing / getBoundingClientRect) rather than the
potentially-rounded getOuterScreenRect, to prevent the resize.
We could fix autoPosition = false, but I don't think it's needed
anymore, so I'm going to try removing it instead. However this change
should still avoid work, so seems worth landing regardless.
[1]: https://searchfox.org/mozilla-central/rev/c5c002f81f08a73e04868e0c2bf0eb113f200b03/layout/xul/nsMenuPopupFrame.cpp#621-626
[2]: https://searchfox.org/mozilla-central/rev/c5c002f81f08a73e04868e0c2bf0eb113f200b03/browser/components/customizableui/PanelMultiView.jsm#668
Depends on D159935
Differential Revision: https://phabricator.services.mozilla.com/D159936
While these work now because I haven't ported popups to modern flexbox,
let's remove usage of these attributes so I don't have to later. This
doesn't change behavior.
Depends on D159934
Differential Revision: https://phabricator.services.mozilla.com/D159935
By using delegatesanchor="true", we delegate the anchor node to the
first in-flow box (that is the icon), simplifying a lot of the
hard-coded margins in the CSS.
Do that, plus make menupopup[type="arrow"] work consistently, to
simplify the styling of the bookmarks popup a bit.
Differential Revision: https://phabricator.services.mozilla.com/D158569
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
These don't work on emulated flexbox. We only have a couple of uses.
See D159726 for the diagnostic patch I used to catch these.
Differential Revision: https://phabricator.services.mozilla.com/D159727
