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
This is the first part of the bug. A clarification in the spec states
that a grid item spanning multiple tracks, which include a flexible
track, should not participate in auto min sizing calculation and should
have a width of 0.
https://w3c.github.io/csswg-drafts/css-grid-1/#min-size-auto
For the reftest, the previous overrides are removed as the correct
behaviour is now implemented.
Differential Revision: https://phabricator.services.mozilla.com/D160900
No need to be an out of band member function given the only callers are
in flex / grid code.
I was looking at this in the context of bug 1798396. This probably
doesn't matter for PGO, but it being a static method helps reason about
the flags being the same for all items.
Differential Revision: https://phabricator.services.mozilla.com/D161102
This patch doesn't change behavior, and eliminates copy construction of
nsFrameList via utilizing const-references to store the return value of
`GetChildList()`.
nsFrameList::Clone() is added in case the caller wants a copy of a list.
This is the first step toward making nsFrameList a move-only class.
Differential Revision: https://phabricator.services.mozilla.com/D160013
This patch doesn't change behavior, and eliminates copy construction of
nsFrameList via utilizing const-references to store the return value of
`GetChildList()`. This is the first step toward making nsFrameList a move-only
class.
Differential Revision: https://phabricator.services.mozilla.com/D160013
After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
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
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
