This ended up being a lot more straight-forward than the menu changes.
TLDR:
* nsMenuBarFrame -> XULMenuBarElement
* nsMenuBarListener -> MenuBarListener
Rest should be rather straight-forward.
Depends on D168649
Differential Revision: https://phabricator.services.mozilla.com/D167809
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
I'm about to extend them for bug 1811486, where I want to force in some
cases the rolled up popups to hide synchronously. These APIs use a ton
of boolean arguments that make them error prone, so refactor them a bit
to use strongly typed enums and flags.
Differential Revision: https://phabricator.services.mozilla.com/D167381
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
See the comment for why we can't just use scrollbar-gutter: stable,
which is what we'd want, ideally.
This is reproducible on Win10 and also Linux as long as:
* Overlay scrollbars are disabled.
* The scrollbar size is bigger than the menulist arrow size.
This used to be done by the chunk of code here:
* 8f61a444ce (l7.82)
Which changed the size of the menu (not just the popup) which then the
popup expanded to. So quite hacky over-all.
Differential Revision: https://phabricator.services.mozilla.com/D165669
I decided to split this up from bug 1805414 because it's only
tangentially related to the removal of nsMenuFrame.
We have this sizetopopup attribute and behavior that allows menulists to
be sized to the contents of the popup. The popup also expands to the
menulist rect.
This means that layout is by somewhat cyclic and we need to go out of
our way to support it. However, I think we only care about the first
behavior. We don't have many non-intrinsically-sized menulists, and
if we need we can use HTML <select> instead, which does have that
behavior.
Simplify the setup to make sizetopopup only apply to menulists (we don't
have non-menulist usage anyways), and only work in the "popup depends on
the menulist" direction, not the other way around.
This will allow making the popup a regular out-of-flow element. The
change to test_menulist_paging is not needed (I restored the behavior of
eagerly layout menulists, to fix the <select> popup, but I'd like to fix
that eventually, so I'd rather leave them in, they're harmless).
Differential Revision: https://phabricator.services.mozilla.com/D164693
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
I decided to split this up from bug 1805414 because it's only
tangentially related to the removal of nsMenuFrame.
We have this sizetopopup attribute and behavior that allows menulists to
be sized to the contents of the popup. The popup also expands to the
menulist rect.
This means that layout is by somewhat cyclic and we need to go out of
our way to support it. However, I think we only care about the first
behavior. We don't have many non-intrinsically-sized menulists, and
if we need we can use HTML <select> instead, which does have that
behavior.
Simplify the setup to make sizetopopup only apply to menulists (we don't
have non-menulist usage anyways), and only work in the "popup depends on
the menulist" direction, not the other way around.
This will allow making the popup a regular out-of-flow element. The
change to test_menulist_paging is not needed (I restored the behavior of
eagerly layout menulists, to fix the <select> popup, but I'd like to fix
that eventually, so I'd rather leave them in, they're harmless).
Differential Revision: https://phabricator.services.mozilla.com/D164693
This reduces the weird interactions that can appear on menus.
This also progresses BiDi support, including for accesskeys.
Differential Revision: https://phabricator.services.mozilla.com/D161498
So that they don't affect the overflow area of the root element. Since
they paint in a different widget over the current one it doesn't make a
lot of sense for them to do so.
They are in the top layer already, so for XUL documents this doesn't
change anything (because there's no root scroll frame and abspos CB
is the same as fixed CB).
For scrollable html documents it does prevent the scroll frame from
accounting for them.
This inverts the destruction order of the default tooltip's
nsMenuPopupFrame and the canvas frame, which caused an interesting leak,
since the tooltip was not getting properly unbound from the
PostDestroyData. nsMenuPopupFrame shouldn't need to manage the default
tooltip anymore, so removing it simplifies the code and also fixes that
leak (which I initially didn't find because I run opt tests by default).
Differential Revision: https://phabricator.services.mozilla.com/D161931
Since they can't paint outside of the widget, it makes sense.
Now that popups are not so special and they just use the top layer we
can enforce it using contain: paint.
This should save some work when adding / removing transforms to popups
(since they won't change the containing block).
Now popups can become dynamic reflow roots, and that caught some issues
with the reflow requests. We need to hit
nsMenuPopupFrame::LayoutPopup(), so the right thing to do is to use
NS_FRAME_IS_DIRTY.
Differential Revision: https://phabricator.services.mozilla.com/D161708
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
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
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
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
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
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
This is a follow-up to bug 1783500. The existing expansion for the
screen area works great on Windows and so on, but on macOS it can
conceptually cause a menulist to go off-screen, because of this margin
used to move menulists to the left:
https://searchfox.org/mozilla-central/rev/f655bdf6b4bf01b42609750ab94fc37635397260/toolkit/themes/osx/global/popup.css#85
Instead we should do the same as that bug did, and use the
input-region-margin, which is the amount of space that has no content
(that is, that contains the shadow and so on) and is zero on macOS
(because shadows on macOS are drawn by the OS unlike on Windows /
Linux).
This required extra test changes so it was worth getting it reviewed
separately.
Differential Revision: https://phabricator.services.mozilla.com/D154401
