commit 117f23cf778605528eb48ba5039657b2455c6f40
author Alison Maher <almaher@microsoft.com> Mon Apr 04 19:31:16 2022
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Mon Apr 04 23:16:39 2022
tree 227d30f71fab68046c982ee78a094a0309b41c99
parent cf8947b098c79c7713ff4d35097ff01d8149e5ef

[FlexNG] Expand row cross size for fragmentation

Previously, for flex rows, when items expanded as a result of
fragmentation, we would only adjust the subsequent rows' offsets based
on the expansion amount. However, we also want to expand the row
block-size to allow items in that row to stretch to the newly expanded
size.

Because flex items in a row can break before, we couldn't implement
this in the same way as grid (i.e. by storing the results and
offsets and then adding them to the builder once all expansion is
handled). Otherwise, we could end up with a child break before added
to the builder before the previous items in the row had been added.

Instead, we need to abort layout and re-run with the updated row
block-sizes (using the newly added layout result status of
kNeedsRelayoutWithRowCrossSizeChanges and the newly added
RelayoutWithNewRowSizes() method).

Since we will re-layout as we go, we can no longer wait to detect
the row expansion until items have completed layout, but we need to
find the max row expansion in each fragmentainer as we go (and as
items cross the current row block-size). As such, we now calculate
row expansion without making use of NGFlexItem's
total_remaining_block_size (as we do for columns).

Because more than one row can expand per fragmentainer, we can avoid
aborting layout more than once by adjusting subsequent row offsets
as expansion is discovered and by keeping track of the expansion
of all rows in a given fragmentainer (there should only be at most two
row expansions at a time, though).

While testing, I ran into a few additional issues:

1. I had noticed a bug with how row expansion was handled for items
that broke before. We would previously adjust the offset of all items
in the row rather than just the offset of the item itself. This is now
fixed by not updating |line_output.item_offset_adjustment| in this
case.

2. When checking if the |broke_before_row| is associated with the
current row, we can't just check if we are at an item at index 0
since a previous item may have broken as a result of overflow.
Check instead if the current item is at index 0 and that it broke
before.

3. When adding |item_offset_adjustment| of one row to the next,
check if the last item has a break token or if the line has seen
all children so that we do so even if the last item overflows. (But
if the last item overflowed, we only want to adjust
|item_offset_adjustment| if there aren't any additional break tokens
to process, in which case the next row would have already started
making progress).

Note: We will stop row expansion if the container's consumed block-size
hits the max to avoid infinite expansion. This keeps the following test
from timing out:
external/wpt/css/css-break/flexbox/flexbox-fragmentation-layout-001-crash.html

multi-line-row-flex-fragmentation-016.html was previously incorrect
since item stretching as a result of row expansion was not yet
implemented. The test is now updated to account for the new
behavior.

Bug: 660611
Change-Id: If4fca22d10a43052a2f0218333d3a74752762b79
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3561235
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#988612}