tree 5252364df8cd397cedcf3bb6dd5c37798b312d01
parent f6f118de16681fc1586f265c2ea7bea98fc7dec9
author Morten Stenshorne <mstensho@chromium.org> 1708070972 -0800
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> 1708072013 -0800

Remove old OOF fragmentation spanner-awareness code.

This was needed back when OOFs didn't affect column balancing. We would
in some cases have to manually create additional fragmentainers when
starting layout of an OOF (with a sufficiently large block-offset)
*after* the spanner, even though the OOF was defined before the spanner.
We no longer do that, now that OOFs affect column balancing.

The code that's now removed had no effect (as far as I can tell) in
non-nested multicol, since we always make room for OOFs before the
spanner. However, it did do something in nested multicol with spanners,
because we'll fail to make enough room for OOFs in cases where they
would cross an outer fragmentainer boundary. What this code did was
wrong in such cases anyway. It would push additional fragmentainers
below the spanner, and not set the right block-size, resulting in
overflowing the outer fragmentation context in the block direction. By
removing this code, we'll now just create additional fragmentainers at
the same block-offset as the last one, progressing in the inline
direction. This is the best we can do (and what we did in all other
cases, anyway), since we don't support creation of additional outer
fragmentainers for OOFs.

Two unit tests have to be updated, because of the above. One of them now
behave correctly, while the other one still isn't quite there. Add a web
test for it as well.

By removing this code, UpdatedFragmentainerOffset() ended up only adding
fragmentainer_progression, if it was a new fragment. Just remove the
function and do the job at the call site instead.

In LayoutOOFsInFragmentainer(), if we find the last fragmentainer
*before* calling GetFragmentainerConstraintSpace(), we won't have to do
the same job in there, since GetFragmentainerConstraintSpace() no longer
needs to know whether it's a new fragmentainer or not.

This doesn't really fix crbug.com/40775119 , but it does improve the
rendering of the demo there.

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