Safer multiple re-layout handling in algorithms.
When we need to re-run a layout algorithm with new information
discovered during layout (e.g. with an early-break, line clamping, text
box trimming, etc.), we'll create a new layout algorithm for the same
node and re-run it. This worked fine as long as we only had to re-layout
once, but not so reliably when re-laying out more than once.
There was some spotty support for handling multiple re-layouts (for the
cases that we had discovered). Table layout, for instance, took care to
re-apply any early-break when we wanted to re-layout at the last table
box fragment. Another example was flex layout, which made sure that
re-layouts for early-breaks and re-layouts for ignoring scrollbar
changes played well together. The block layout algorithm also had
special-code for combining early-breaks and column spanner paths.
Instead of adding code to handle each combination as we discover
problems with them, introduce a generic solution.
This fixes one known problem: a stack overflow issue where the
early-break machinery started to fight with the text-box-trim machinery,
both wanting a re-layout, without being aware of the other, leading to
an infinite recursion. Note that text-box-trim still doesn't work
correctly inside block fragmentation, but at least we'll no longer
crash.
Had to move the column spanner path check out of BlockLayoutAlgorithm()
and into Layout(), now that we're setting this member after construction
(SetupRelayoutData()).
Change-Id: I04a0d1c26f093d8bb8cdc2dda473c46bd0df4a18
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5937811
Commit-Queue: Morten Stenshorne mstensho@chromium.org
Reviewed-by: Koji Ishii kojii@chromium.org
Cr-Commit-Position: refs/heads/main@{#1369838}