This is the spec describing flex container baselines.
https://drafts.csswg.org/css-flexbox-1/#flex-baselines
* Separate the cache for last baseline in FlexItem. This is needed beacuse we set
an item's first baseline via `SetAscent()` after reflowing it. Any query to last
baseline via `ResolvedAscent(false)` will wrongly return the first baseline.
* We used to compute flex container baseline from the first item in
ReflowChildren(). Now we consolidate all the logic computing flex container
baseline in PopulateReflowOutput().
Differential Revision: https://phabricator.services.mozilla.com/D181604
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
ReflowChildren() needs more bookkeeping data to correctly place tall flex items
being pushed from prev-in-flows during fragmentation. This is a preparation for
bug 1743890 that is going to add more fields to the struct.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D164399
- Remove the return value since it is never used.
- Store the newly create flex item in a reference since EmplaceBack() returns
NonNull<FlexItem*>.
Differential Revision: https://phabricator.services.mozilla.com/D164396
This patch doesn't change behavior. The changes were auto-generated by the
following command:
./mach clang-format -p layout/
Differential Revision: https://phabricator.services.mozilla.com/D160552
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
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
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
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 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
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
CachedBAxisMeasurement::mAscent caches the ascent of a flex item after
the measuring reflow, but the ascent may change after the final reflow
if the item is stretched and does some vertical alignment internally.
However, we don't cache the new ascent. Therefore, when we reflow the
item incrementally, if the CachedBAxisMeasurement::Key is valid, we just
skip the measuring reflow, and retrieve the wrong ascent from the cache.
Instead of fixing this bug by updating the cached ascent or rejecting
the ascent cache for a stretching flex item in block axis, this patch
removes the cache and sets ReflowOutput's BlockStartAscent() to the flex
item after the item's measuring reflow. (We've done the same after the
item's final reflow.) If the ascent is ReflowOutput::ASK_FOR_BASELINE,
we resolve in FlexItem::ResolvedAscent() anyway.
Differential Revision: https://phabricator.services.mozilla.com/D121404
Some of our GetNaturalBaselineBOffset implementations already have this; others
don't. But they all should have it, or else a caller might improperly query
their baseline and use it for layout despite the frame having 'contain:layout'.
Without this patch, the rest of this patch-stack makes us fail WPT test
contain-layout-suppress-baseline-002.html because we improperly honor the
baseline for the 'contain:layout' buttons at the top of the test.
Differential Revision: https://phabricator.services.mozilla.com/D121938
CachedBAxisMeasurement::mAscent caches the ascent of a flex item after
the measuring reflow, but the ascent may change after the final reflow
if the item is stretched and does some vertical alignment internally.
However, we don't cache the new ascent. Therefore, when we reflow the
item incrementally, if the CachedBAxisMeasurement::Key is valid, we just
skip the measuring reflow, and retrieve the wrong ascent from the cache.
Instead of fixing this bug by updating the cached ascent or rejecting
the ascent cache for a stretching flex item in block axis, this patch
removes the cache and sets ReflowOutput's BlockStartAscent() to the flex
item after the item's measuring reflow. (We've done the same after the
item's final reflow.) If the ascent is ReflowOutput::ASK_FOR_BASELINE,
we resolve in FlexItem::ResolvedAscent() anyway.
Differential Revision: https://phabricator.services.mozilla.com/D121404
If the flex container frame's tentative border-box size is different
from its final size, and it's in vertical-rl writing mode, we need to
adjust children's position. This is implemented in Part 3.
Differential Revision: https://phabricator.services.mozilla.com/D97521
If the flex container frame's tentative border-box size is different
from its final size, and it's in vertical-rl writing mode, we need to
adjust children's position. This is implemented in Part 3.
Differential Revision: https://phabricator.services.mozilla.com/D97521
This removes virtually all the time under ConsumedBSize. See the comment for
what ensures the correctness of the cache: Basically, we refresh the cache for
a frame continuation every time we reflow it, which means that when next
continuations go look for it it should be up-to-date (we rely on that already
because we're looking at the content rect).
Differential Revision: https://phabricator.services.mozilla.com/D97357
This removes virtually all the time under ConsumedBSize. See the comment for
what ensures the correctness of the cache: Basically, we refresh the cache for
a frame continuation every time we reflow it, which means that when next
continuations go look for it it should be up-to-date (we rely on that already
because we're looking at the content rect).
Differential Revision: https://phabricator.services.mozilla.com/D97357
