Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
After this patch, we'll fail four tests due to reference files written in grid
layout, and we've had bug 1609403 for grid baseline alignment.
Differential Revision: https://phabricator.services.mozilla.com/D185872
When iterating flex line and flex item in ReflowChildren(), start from the
startmost line and startmost item with respect to the flex container's
writing-mode. This is equivalent to iterate the items in visual order, which is
necessary to compute the item's position correctly, because any shift to the
startmost line or startmost item can affect later ones.
Also, change a condition in `Reflow()` to `aReflowInput.IsInFragmentedContext()`
so that the necessary data can be updated when the flex container fragment is
reflowed in the last column. Otherwise, there will be "unexpected max block
size" assertions [1] while running `layout/generic/crashtests/1666592.html`.
[1] https://searchfox.org/mozilla-central/rev/e9b8c73771d0038214c69f17c5934ba8ae049799/layout/generic/nsFloatManager.cpp#111
Differential Revision: https://phabricator.services.mozilla.com/D183193
Likewise, we should also consider first baseline in the endmost line when
computing flex container last baseline.
Fixed the XXX comment by using logical coordinates. This is necessary to pass
flex-align-baseline-flex-004.html because it tests a vertical-rl flex container.
Differential Revision: https://phabricator.services.mozilla.com/D182432
The idea behind this change is for flex items with swapped block-flow direction
to end up in swapped baseline-sharing groups on the flex container's FlexLine.
The outcome of this is that all of the baseline-aligned flex items that are
using a baseline on their left edge will be aligned together (e.g. in the
"first" group), and all of the flex items with a baseline on their right edge
will be aligned together (e.g. in the "last" group), even if they may have
varying block-flow directions (vertical-lr vs. rl) and varying `align-self`
values.
This is rooted in the idea of baseline alignment preferences being "compatible"
as defined here:
https://drafts.csswg.org/css-align-3/#compatible-baseline-alignment-preferences
This makes us start passing a bunch of WPT tests; this patch removes the
corresponding .ini files for those tests that are now passing.
Differential Revision: https://phabricator.services.mozilla.com/D181824
This patch doesn't affect behavior; it's just a refactoring to prepare for the
next patch in this series.
(As of this patch, the BaselineSharingGroup is always the same as the
'align-self' baseline selection, but the next patch will change that.)
Differential Revision: https://phabricator.services.mozilla.com/D181823
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
This patch deals with two things:
1. Push tall monolithic flex items to next-in-flow, and adjust their positions.
2. Grow flex container's block-size if its block-size is unconstrained.
This patch doesn't fix:
1. Item shifts in different lines in a multi-line column-oriented container
(bug 1806717).
2. Flex container block-size grow due to flex item's block-size grow in
fragmentation.
If a flex item has break-before:avoid, we don't want to push it to the
next-in-flow (in the computaion of `shouldPushItem`). Otherwise, we'll fail
web-platform/tests/css/css-break/flexbox/multi-line-column-flex-fragmentation-034.html
Differential Revision: https://phabricator.services.mozilla.com/D165192
MoveFlexItemToFinalPosition() already has a log printing flex item's position.
This patch adds a log in ReflowFlexItem() to print flex item's position, too.
Differential Revision: https://phabricator.services.mozilla.com/D165191
Make display: -moz-box's visibility: collapse handling switchable by its
own CSS property.
Longer term maybe we should switch the front-end away from visibility:
collapse altogether (there are some alternatives), but for now this will
allow to move the front-end to switch to modern `display: flex` while
keeping `visibility: collapse` work as in -moz-box.
Differential Revision: https://phabricator.services.mozilla.com/D171472
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
nsColumnSetFrame can reflow its last column in an unconstrained available
block-size to measure the total block-size of the content [1]. This patch adds a
helper method in ReflowInput for that.
For flex items in a fragmented context, we *cannot* skip its final reflow
because fragmentation might grow its block-size if there's any force break in
it (bug 1663079), or if it has repeated table header/footer (bug 1744363).
This patch doesn't change observable behavior for now. Before this patch, we may
skip an item's final reflow if it is in a flex container's continuation that is
in the last column with an unconstrained available block-size. As of this patch,
the item will be reflowed. This is a partial step towards fixing the above bugs
where the item's block-size may grow.
[1] https://searchfox.org/mozilla-central/rev/daf613efc5c358f3a94961d73b90472c00703838/layout/generic/nsColumnSetFrame.cpp#614-621
Differential Revision: https://phabricator.services.mozilla.com/D167207
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
When I first implemented flexbox fragmentation, all the children in flex
container's next-in-flows are all put in one FlexLine, because we assume the
position of flex items won't shift in fragmentation. However, when we implement
more granular control of flexbox fragmentation such as pushing a tall flex item
to next page/column, we'll need the information of flex lines.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D164398
