Keep track of whether we have any collapsed items, since we're already
looking at it while generating them.
No behavior change intended.
Differential Revision: https://phabricator.services.mozilla.com/D158627
Make it work as a min-size everywhere rather than only handling it in
nsIFrame::ComputeSize.
This is more similar to what XUL code does. In particular, it makes
makes it work for elements that don't have a definite size in
ComputeSize (like flex containers).
For web-exposed widgets this only matters for <input type=color> and
<input type=range>, which are the only exposed widgets that return a
minimum size that return a minimum size. This patch makes the minimum
size honored for `<input type="color" style="height: auto">`. Add a test
for that (though we might want to change it to match other browsers).
Without this fix, min/max/close buttons on Linux are zero-height with
flex emulation, because we fail to account for their minimum
widget-imposed size.
This allows us to remove the special case in nsFlexContainerFrame too,
since that should be handled by ReflowInput correctly now.
Differential Revision: https://phabricator.services.mozilla.com/D158612
The XUL behavior in nsBox.cpp is fairly different to what the non-XUL
layout code paths do. In particular, canOverride=false means that the
min-{width,height} properties cannot go under the min widget size of the
widget, but that doesn't mean that intrinsic sizes don't affect the
final size of the widget.
This is very visible if you turn on flex emulation on Windows or macOS,
where the toolbar has an appearance that returns
width=0,height=N,canOverride=false.
With flex emulation we'd collapse the item to be zero-width, which is
not good at all.
The good thing is that this is no longer exposed to the web
(non-native-theme always returns canOverride=true), and our front-end
code doesn't seem to rely on this, so we can just remove support for
canOverride=false.
Differential Revision: https://phabricator.services.mozilla.com/D158608
Recently we added different bits for -webkit-/-moz- box emulation, so we
no longer need to go look at the scrolled frame etc.
Differential Revision: https://phabricator.services.mozilla.com/D158603
Instead of digging into the first line-iterable frame. Digging into the
first line-iterable frame is bogus, because if there are multiple flex
items we might prevent moving through them properly (see test-case).
The flex implementation is nice and fairly complete, IMO. The grid one
is not, but the resulting behavior is nicer than the behavior before
this patch, seems reasonable, and matches Chrome in my testing.
In Searchfox, the behavior is even funnier because user-select: none is
involved, but that predates the regression.
Differential Revision: https://phabricator.services.mozilla.com/D158086
Before this patch, we honored `align-content` (in combination with
`align-self`) for cross-axis alignment for abspos flex children **in cases
where the flex container was multi-line**. This was a bit weird, but was
required by the spec, and made some sense in the spirit of aligning the abspos
box as if it were the sole flex item in a flex container.
Now the CSSWG has resolved in [1] to simplify things by just ignoring
`align-content` for abspos flex children. So, this patch updates us in
accordance with this change. Such items now only have to look at `align-self`
for cross-axis alignment to determine their static position in their flex
container.
Before this commit, we had a bunch of WPT tests to check the impact of every
align-content value, with all of the various flavors of directionality. Now
that align-content has *no effect* in any of these cases, all of these tests
become pretty trivial and redundant. Rather than carrying them all forward
with trivial "no impact" expectations for each scenario, I've just updated the
first/simplest such test to expect no-behavioral-impact and I've removed the
rest.
[1] https://github.com/w3c/csswg-drafts/issues/7596#issuecomment-1225952646
Differential Revision: https://phabricator.services.mozilla.com/D157571
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D156473
ReflowChildren() only cares about the flex item's normal position, so we don't
need to output the relative position from `MoveFlexItemToFinalPosition()`.
By making `aFramePos` const for `MoveFlexItemToFinalPosition`, we can delete
`itemNormalBPos` because `framePos` cannot be changed after calling
`MoveFlexItemToFinalPosition`.
This patch shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D157079
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 is a hack, sorta, similar to Chromium's:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_object.cc;l=356;drc=312b74e385e6aba98ab31fd911238c0dc16b396c
except at computed-value rather than used-value time, because it's both
simpler to reason about and prevents lying in the computed style.
This fixes the relevant test-case, and matches closer what Chromium does,
by not creating anonymous flex items for all elements inside the
line-clamp context.
The behavior change is covered by the test changes. I had to also fix a
couple pre-existing bugs that were caught by tests, now that the
line-clamped block is the -webkit-box-styled element rather than an anonymous
flex item (and thus now had padding).
Depends on D155180
Differential Revision: https://phabricator.services.mozilla.com/D155181
This bug is regressed by Bug 1686603 Part 4 [1]. When the used flex-basis is
'content', the old code computes flex base size by using 'auto' as the main size
in `nsContainerFrame::ComputeSizeWithIntrinsicDimensions()`. The method is for
replaced elements to compute sizes, even if the element has no preferred
aspect-ratio such as an `<svg>` without viewBox nor aspect-ratio property.
However, Bug 1686603 Part 4 made replaced elements without preferred
aspect-ratio uses 'max-content' when computing flex base size. Unfortunately, we
only trigger the replaced elements intrinsic sizing via 'auto' but not via
'max-content', so this patch restores the behavior via emplacing 'auto' in
`styleFlexBaseSize`.
[1] https://phabricator.services.mozilla.com/D101795
Differential Revision: https://phabricator.services.mozilla.com/D155628
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
Note this patch only prevents "break-inside:avoid" flex containers from being
broken when they are not at the top of their current page/column. When they are
at the top of their current page/column, this patch fails to help since
`nsContainerFrame::ShouldAvoidBreakInside()` returns `false` via the
`mIsTopOfPage` check. This is essentially bug 793686.
Differential Revision: https://phabricator.services.mozilla.com/D149318
This patch shouldn't change the behavior.
* It's OK to get the item's offset only when its relatively positioned, because
`ApplyRelativePositioning` doesn't use the offset parameter if the frame is
sticky positioned. Document `ApplyRelativePositioning`'s parameters to clarify
this. Also, we don't need to call apply relative positioning to a
non-relatively-and-non-sticky-positioned item.
* Print `FLEX_LOG` after applying relative-positioning because `aFramePos` will
be adjusted in `ApplyRelativePositioning`, and we really want to see the
item's "final position".
* `aReflowInput` parameter is removed because it's only used to get flex
container's WritingMode. We can get it from FlexItem.
Differential Revision: https://phabricator.services.mozilla.com/D140703
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
Currently, we pass all the five fields in FlexLayoutResult separately into
ReflowChildren(), but we really should just pass FlexLayoutResult instead.
Differential Revision: https://phabricator.services.mozilla.com/D138100
We've got the tentative cross size before calling DoFlexLayout() in Reflow(), so
we can just use that value in DoFlexLayout and a few other methods.
Also, add "ContentBox" to naming of the main size argument ComputeMainSize().
Differential Revision: https://phabricator.services.mozilla.com/D137365
I found in/out parameters confusing when reasoning the data flow. Aggregating
DoFlexLayout's output data in a struct also reduces DoFlexLayout's number of
arguments.
Differential Revision: https://phabricator.services.mozilla.com/D137364
The `struts` array is used only within DoFlexLayout, so we should move it into
`if (!GetPrevInFlow()) { ... }` branch.
Also, move `nsTArray<StrutInfo>&` argument on DoFlexLayout() to the second to
last place so that the output arguments are grouped together after applying Part
4.
Differential Revision: https://phabricator.services.mozilla.com/D137363
Move the assertion for unconstrained isize to the beginning of Reflow() because
we check it in all cases -- in GetMainSizeFromReflowInput when a flex container
is row-oriented, or in the old code computing gap size and ComputeCrossSize()
when a flex container is column-oriented.
Differential Revision: https://phabricator.services.mozilla.com/D137361
We introduced this comment at the very beginning of the flexbox implementation.
Since then, WritingModes.h has obtained the utilities dealing with logical axis,
and CSSAlignUtils.h has supported CSS alignment for both flexbox and grid. All
the helper functions remaining in nsFlexContainerFrame.cpp are related to
flexbox, so I feel it's time we retire this comment.
NPOTB DONTBUILD because this patch changes only comments.
Differential Revision: https://phabricator.services.mozilla.com/D134652
In Flexbox spec 4.1, Example 3 [1]:
... since the absolutely-positioned box is considered to be
"fixed-size", a value of stretch is treated the same as flex-start.
Also, per Alignment 3 spec [2]:
The default fallback alignment for 'stretch' is 'flex-start'.
Thus, when computing the alignment for flexbox's abspos children in
CSSAlignmentForAbsPosChild(), we convert 'stretch' to 'flex-start', and let the
subsequent logic convert 'flex-start' to either 'start' or 'end', because
nsAbsoluteContainingBlock don't know how to deal with the flex-relative axis.
This patch makes us behave the same as Google Chrome on the modified testcases.
[1] https://drafts.csswg.org/css-flexbox/#abspos-items
[2] https://drafts.csswg.org/css-align/#valdef-align-content-stretch
Differential Revision: https://phabricator.services.mozilla.com/D134543
