This patch only changes behavior in cases where the following conditions hold:
(a) We're asking an item for its baseline, and the item has a writing-mode
that uses a central baseline (e.g. vertical-rl).
(b) We're asking for a baseline **in that item's inline axis**, i.e. a
measurement in the y-axis.
In this situation, the item really only wants to use central baselines for its
own block-axis baselines, not for its inline-axis baselines. So let's not
bother trying to generate central baselines in its inline axis.
This is documented to some extent in
https://www.w3.org/TR/css-writing-modes-4/#text-baselines, which describes
central baselines as being between the 'over' and 'under' edges (aka
'line-over' and 'line-under'), i.e. a measurement in the element's own block
axis.
This makes us pass WPT subgrid-stretch.html, because it happens to depend on
the baseline alignment of horizontal-writing-mode grids that have
vertical-writing-mode subgrids.
Differential Revision: https://phabricator.services.mozilla.com/D196932
This patch does two things:
1. Extends ShouldInhibitSubgridDueToIFC to return true for out-of-flow frames,
per spec (which makes us pass the WPT independent-formatting-context.html).
Spec reference: https://drafts.csswg.org/css-grid-2/#subgrid-listing
"...if the grid container [the one that's styled to be a subgrid] is
otherwise forced to establish an independent formatting context (for
example, due to layout containment or absolute positioning), the used value
is the initial value, 'none', and the grid container is not a subgrid."
2. Removes some newly-dead code from ComputeSelfSubgridMasonryBits that
provided some special handling for out-of-flow subgrids (which are now
impossible to create, as of this change); and also remove
WillHaveAtLeastOneTrackInAxis() whose last caller I'm removing here.
3. Renames a variable 'gridParent' to 'parentGrid' to match the spec
terminology at https://drafts.csswg.org/css-grid-2/#parent-grid
Differential Revision: https://phabricator.services.mozilla.com/D193731
This patch doesn't change behavior.
The code that follows the new early-return is all in the service of making
changes to the return value `bits`; and all of the modifications are guarded
directly or indirectly by checks for `!inhibitSubgrid`. So we might as well
just morph this `inhibitSubgrid` variable into an early-return and skip all of
that code entirely when it evaluates to true.
Differential Revision: https://phabricator.services.mozilla.com/D196900
This ComputeSelfSubgridMasonryBits() function has some logic to determine
whether a grid is using subgrid layout (i.e. participating in a parent grid)
and also whether it's using masonry layout at all.
There's one early-return for a case where we can't be a subgrid, which
inadvertently also disregards the masonry state that we've set. It looks like
this was an oversight, since in fact we can still use masonry regardless of
whether we're allowed to be a subgrid.
Differential Revision: https://phabricator.services.mozilla.com/D196891
Rename to make them clearer that they stores child's axes in grid container's
writing-mode. Without the "InWM" suffix, it's a bit confusing why not just use
`eLogicalAxisInline`.
Differential Revision: https://phabricator.services.mozilla.com/D196703
When a grid item is set to align itself to the baseline (first or last)
then it should participate in baseline alignment if the item's size is
not dependent on the size of the track and vice versa.
Also added a test to check for last baseline alignment in addition to
first baseline alignment on empty blocks.
Differential Revision: https://phabricator.services.mozilla.com/D157345
When a grid item is set to align itself to the baseline (first or last)
then it should participate in baseline alignment if the item's size is
not dependent on the size of the track and vice versa.
Also added a test to check for last baseline alignment in addition to
first baseline alignment on empty blocks.
Differential Revision: https://phabricator.services.mozilla.com/D157345
When a grid item is set to align itself to the baseline (first or last)
then it should participate in baseline alignment if the item's size is
not dependent on the size of the track and vice versa.
Also added a test to check for last baseline alignment in addition to
first baseline alignment on empty blocks.
Differential Revision: https://phabricator.services.mozilla.com/D157345
I forgot to use a reference when doing the refactoring. We should use a
reference to a pointer because we rely on the information from the previous
iteration, in the private function, `AddImplicitNamedAreasInternal()`.
Note: I don't have a test for this. This bug is from a real website:
https://www.oddbird.net/tools/, and it's not easy to reduce the
testcase, so we may need a QA to verify this by the real website.
Differential Revision: https://phabricator.services.mozilla.com/D195388
When a grid item is set to align itself to the baseline (first or last)
then it should participate in baseline alignment if the item's size is
not dependent on the size of the track and vice versa.
Also added a test to check for last baseline alignment in addition to
first baseline alignment on empty blocks.
Differential Revision: https://phabricator.services.mozilla.com/D157345
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
We introduce a different rust type for `<line-name-list>` for subgrid,
which keeps `repeat()` information at computed time. At this moment,
we don't expand `repeat()`.
Also, we precompute the possible expanded list length, so we can expand
`repeat(auto-fill)` in a single iteration in nsGridContainerFrame. If we
don't have this precompution, we have to go through `<line-name-list>`
first to know how many items we have after expanding `repeat(Integer)`.
Differential Revision: https://phabricator.services.mozilla.com/D192876
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
This ensures that repeated calls to Element::GetGridFragments will return
an array of idempotent Grid objects for each fragment. This is
accomplished by making the Grid object hold a WeakFrame back to its
originating frame, and updating a property on construction and
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D169724
This ensures that repeated calls to Element::GetGridFragments will return
an array of idempotent Grid objects for each fragment. This is
accomplished by making the Grid object hold a WeakFrame back to its
originating frame, and updating a property on construction and
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D169724
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
