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
For that, we need to min-width: 0 the nav-bar target, which itself
requires us to tweak the overflow detection so that we look at all
children of the customization target, not only the target itself.
Differential Revision: https://phabricator.services.mozilla.com/D159377
This simplifies the widget tracker code to avoid having to remove random
width attributes in all children.
Resize only the searchbar, since that's the only thing that's
effectively restored already on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D159071
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
This is needed to fix browser_ext_browserAction_click_types.js.
Before the first patch in this bug, the order of the built-in command
event and the synthetic event here was slightly different, so it was
papered over. Also, the click event will trigger a command event if
needed, so there's no need to do it explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D157591
(To be landed right after the soft freeze is over)
One interesting consequence of my previous patch in this bug, is that
the time at which the XUL element processes the click event is different
(earlier, at bubbling phase rather than after everything).
This caused some test failures caused by the panel autohide, since now
it goes after than the native handling and the native handling
default-prevents to dispatch the XUL command.
Given we don't check key events for defaultPrevented either, it makes
sense to be consistent.
This uncovered an interesting failure, where the "show more tabs" button
in the sync menu starts closing the panel unexpectedly on click. The
right fix is to use closemenu="none" in that button, since otherwise
that button is not keyboard accessible (this is an issue on current
nightly that this patch fixes).
Differential Revision: https://phabricator.services.mozilla.com/D157584
My guess is that this didn't use to fail so much because
_getOverflowInfo was effectively synchronous before, but after my patch
the flush is lazy, and the promiseDocumentFlushed call is actually
async.
With this change I can't reproduce the failure locally anymore, while
it's trivial to repro this failure with --run-until-failure before this
change.
Differential Revision: https://phabricator.services.mozilla.com/D156418
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
