This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
- Create wheel transactions for wheel events handled by APZ.
- Group wheel events with the current wheel transaction, so that all
wheel events in a wheel transaction are fired to the same element.
- Store the current event target for the first event in a wheel
transaction to be used for subsequent events.
- Add the dom.event.wheel-event-groups.enabled preference as a feature
flag for this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D163484
The underlying issue here is an invalidation bug with XUL layout. When a
popup opens, we try to lay it out at full size, then post a reflow
callback to constrain it.
There's an intermediate step there where the popup might remain at full
size, and the constraining operates directly on mRect, which isn't quite
sound and doesn't update the scrollport of descendants.
Make nsMenuPopupFrame inherit from nsBlockFrame instead, doing
potentially two layout passes when constrained.
This fixes the issue at hand, and removes XUL layout from menu popups,
so it's a win-win.
To make reasoning about it a bit easier, factor out a bunch of the XUL
positioning code to be const. The mutation of mRect etc which was going
on otherwise was pretty hard to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D170368
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
Done mostly automatically via find/replace following the conversions
specified here:
https://groups.google.com/a/mozilla.org/g/firefox-dev/c/9sGpF1TNbLk/m/QpU3oTUuAgAJ
For the most part I think the "flex: N N" usage could be simplified to
just "flex: N", but I wanted to preserve behavior (-moz-box-flex sets
both flex-grow and flex-shrink).
I changed legacy layout to also look at the order property rather than
-moz-box-ordinal-group because it made splitters and treecols easier (we
don't need to deal with both orders).
Differential Revision: https://phabricator.services.mozilla.com/D171715
Done mostly automatically via find/replace following the conversions
specified here:
https://groups.google.com/a/mozilla.org/g/firefox-dev/c/9sGpF1TNbLk/m/QpU3oTUuAgAJ
For the most part I think the "flex: N N" usage could be simplified to
just "flex: N", but I wanted to preserve behavior (-moz-box-flex sets
both flex-grow and flex-shrink).
I changed legacy layout to also look at the order property rather than
-moz-box-ordinal-group because it made splitters and treecols easier (we
don't need to deal with both orders).
Differential Revision: https://phabricator.services.mozilla.com/D171715
- Create wheel transactions for wheel events handled by APZ.
- Group wheel events with the current wheel transaction, so that all
wheel events in a wheel transaction are fired to the same element.
- Store the current event target for the first event in a wheel
transaction to be used for subsequent events.
- Add the dom.event.wheel-event-groups.enabled preference as a feature
flag for this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D163484
I knew this sounded familiar, see bug 1811466.
The patch is a one-liner, the rest is a test. I'd ask smaug for review
but he's on PTO so... Markus, maybe you can take a look?
Differential Revision: https://phabricator.services.mozilla.com/D170269
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
This fixes the main issue, and makes the test pass by avoiding issues with the
window sticking around after test completion, messing up future runs.
Differential Revision: https://phabricator.services.mozilla.com/D166119
This worked pre-patch because IsOnMenu() returned true not for all
popups, but only for <menupopup>. Instead, I think it's clearer to just
treat menulists as never-inside-a-menu.
Differential Revision: https://phabricator.services.mozilla.com/D166247
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
On platforms with scrollbar size > dropmarker width the popup is not
guaranteed to be bigger than the menulist after this patch and
bug 1805694 (given the "menu sizes to popup" behavior changed there).
Ensure the popup is sized to the menulist by widening the later.
MANUAL PUSH: Trivial test fix CLOSED TREE
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
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Emilio Cobos Álvarez
Sandor Molnar
Cristina Horotan
Dan Robertson
Norisz Fay
Stanca Serban
Brad Werth
Iulian Moraru
Matthias Camenzind
Marian-Vasile Laza
Mark Banner
Gijs Kruitbosch
Edgar Chen
Nika Layzell
Csoregi Natalia
Stephen A Pohl
Cristian Tuns