GitLab

If we're in a nested fragmentation context (multicol in multicol, for
instance), we may end up in a situation where we have no outer
fragmentainer space left to lay out inner columns. In such cases, if we
cannot fit anything at all, we'll now abort the column layout algorithm,
produce no fragment, and break before the multicol container (or even
earlier), and try again in the next outer fragmentainer.

This introduces another non-successful status for NGLayoutResult, which
all Layout() invokers need to handle as part of block fragmentation.
This doesn't really add much complexity, though: To participate in block
fragmentation, one needs to invoke MovePastBreakpoint() somehow
(possibly via BreakBeforeChildIfNeeded()) anyway, which will refuse to
move past if layout aborted. Apart from that, the only thing callers
need to take care of, is check if layout was successful before trying to
access the physical fragment of the result (since there'll be none if
layout was unsuccessful).

This CL only aborts multicol layout - we still lay out regular blocks
even in cases where we could have told up front that we're past the
fragmentainer boundary. Actually, even if there's a forced break before
a child, we'll lay it out, and let the container break before it
afterwards (and thus discard the fragment that we wasted time on
producing). We might want to change that as well in the future, if it
gives any benefits apart from minuscule performance improvements.

Bug: 829028
Change-Id: I473e7106fcc62921d71567d9496ca4c8a9729b05
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2023833Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736279}