After bug 1665476, it's pretty much a regular XUL box with a couple
special-cases that we can use IsRootElementStyle for. Do that, and allow
using nsFlexContainerFrame when using flexbox emulation.
Differential Revision: https://phabricator.services.mozilla.com/D158288
Now that this doesn't involve an attribute lookup it's not worth it, and
this allows querying the flex of emulated flex items without hitting
assertions due to the lack of box metrics.
Differential Revision: https://phabricator.services.mozilla.com/D157696
I haven't spotted any UI regression from this, and this should generally
make the XUL -> modern flex transition easier, and simplify some
of the relevant code.
This does fix a few layout issues with emulated flexbox.
For the most part, this shouldn't change behavior without that. This
changes behavior if you have mixed inline/non-inline content in the same
XUL box (before they'd get a single item, now you'd get the flexbox /
grid behavior of one item per inline run), and multiple inline-elements
(which would become their own flex items). But I pushed a patch with
some asserts and they didn't fire on our browser mochitests, so I think
we're good.
The UA rule refactoring (removing the inherit from xul anon blocks)
shouldn't matter in practice, since we only have one item (so
box-ordinal is irrelevant) and they have overflow: visible (so
text-overflow and overflow-clip-box shouldn't have an effect).
Differential Revision: https://phabricator.services.mozilla.com/D156375
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
Build errors being fixed here:
layout/xul/nsDeckFrame.cpp:164:43: error: unknown type name 'nsSetAttrRunnable'
layout/xul/nsMenuBarListener.cpp:45:7: error: cannot initialize a member subobject of type 'mozilla::dom::EventTarget *' with an rvalue of type 'nsINode::Document *' (aka 'mozilla::dom::Document *')
(...where "Document" is not defined; this patch includes the header that defines it, which fixes this.)
layout/xul/nsBoxFrame.cpp:270:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
dist/include/nsIRollupListener.h:36:38: error: no type named 'LayoutDeviceIntPoint' in namespace 'mozilla'
(For this error, this patch is changing a header outside of layout/xul, but
it's still required in order for layout/xul to build properly, since it's
#included by layout/xul/nsXULPopupManager.cpp (indirectly, via its .h file).
Differential Revision: https://phabricator.services.mozilla.com/D138092
Bug 1718629 did this for the maximize button. This patch does the same for minimize and close, which we are switching to for consistent tooltip styling.
Differential Revision: https://phabricator.services.mozilla.com/D125625
Windows 11's Snap Layouts feature generates a window of layout options when the maximize window button is moused over. This requires the WM_NCHITTEST message to handle hit detection for the button. Since WM_NCHITTEST messages are very common, although we limit them to no more than every 50ms, we don't want to do a full hit test each time. Instead, we cache the maximize button rect in the widget when it is positioned during layout.
Differential Revision: https://phabricator.services.mozilla.com/D123982
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
Instead, sort stuff using CSSOrderAwareFrameIterator. The current
sorting is broken in presence of dynamic insertions, consider the
following <Child(order)> combination in the DOM:
<A(1000)> <B(0)>
That'd look like:
<B(0)> <A(1000)>
On the frame tree. However when appending a child before B so that the
DOM looks like:
<A(1000)> <C(0)> <B(0)>
The frame constructor will properly insert after A, and the reordering,
which is stable, will end up with:
<B(0)> <C(0)> <A(1000)>
Which is the wrong frame tree order.
We only use -moz-box-ordinal-group in regular sprocket layout, so just
handle it there rather than everywhere. Similarly, we only rely on it
for in-flow stuff, so remove the test for that added in bug 877890 (flex
changed behavior afterwards, interestingly enough).
Differential Revision: https://phabricator.services.mozilla.com/D94790
The only thing in nsIFrame.h that was using it was the implementation
of a templated method, which could be moved to nsIFrameInlines.h.
Depends on D91504
Differential Revision: https://phabricator.services.mozilla.com/D91505
I had written this on one of my attempts to fix the missing text on
reddit when printing, but I think it's worth landing anyways not only
because it's slightly cleaner, but because it avoids the virtual call
and style checks when we're not printing.
This should be an idempotent change.
Differential Revision: https://phabricator.services.mozilla.com/D89171
This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
