Bug 1734921 [wpt PR 31168] - [FlexNG] Initial set-up for single-line column flex...

Bug 1734921 [wpt PR 31168] - [FlexNG] Initial set-up for single-line column flex fragmentation, a=testonly

Automatic update from web-platform-tests
[FlexNG] Initial set-up for single-line column flex fragmentation

Spec: https://drafts.csswg.org/css-flexbox-1/#pagination

There are four different algorithms for fragmenting flex items
depending on the type of container. The first of which I will be
focusing on is fragmentation for a single-line column flex container
since it will be most similar to normal block fragmentation.

Because we need to know the item location before fragmenting, an
additional layout pass was added to NGFlexLayoutAlgorithm::
GiveLinesAndItemsFinalPositionAndSize() to take fragmentation into
account, at which point we know the final block offset of the item.
The looping mechanism in this method was replaced by a newly added
NGFlexItemIterator, which will iterate over items with break tokens
first, and continue from sibling items thereafter.

The code to set up the constraint space for item layout in
BuildSpaceForLayout() was updated with an additional call to
SetupSpaceBuilderForFragmentation() in the final fragmentation layout
pass.

Because we re-layout the entire flex container on every pass, and then
perform a final layout pass taking fragmentation into account, a new
bool was added to the constraint space's RareData to keep track of when
to avoid caching. We want to avoid caching the initial (non-fragmenting)
layout pass - this prevents the fragmented results from getting
overridden each time. There may be potential to avoid this if we can
store this information between fragmentainers, or if we cache it in a
new slot type instead of not caching at all.

With this CL, we can now support fragmentation for a single item in
a single-line column flex container that spans several fragmentainers.
In order to support multiple fragmented sibling items, additional work
will need to be done - including proper block offset calculation,
intrinsic block size calculation, and handling of a break before, all
of which have TODOs.

Some other interesting open questions and areas of investigation
include (TODOs included in the code for these, as well):

- How will the devtools logic work when items have multiple fragments?
- An additional layout pass is already made for items that stretch via
ApplyStretchAlignmentToChild(). It would be optimal if we could
make use of this layout pass to apply fragmentation, as well, to avoid
yet another layout pass in this case.
- How to handle flexbox writing mode roots? They are currently treated
as monolithic.

Bug: 660611
Change-Id: I35bcf407bbf741bb5df71f2acc70767be74090c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3212348
Reviewed-by: David Grogan <dgrogan@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#933725}

--

wpt-commits: e4b78613c5152a38fe6712643dcbe7582591427f
wpt-pr: 31168