GitLab

These fragmentainers are created naturally by the block layout
algorithm. CL:1766070 added code to ignore them (just drop them on the
floor), but it seems that it's less cumbersome to just keep them. We
kept them anyway, if there were unhandled OOFs inside (and manually
propagating such OOFs sounds messy). In addition, we end up with empty
fragmentainers if the first child of a multicol container is a spanner.
Even if we discarded the actual fragmentainer, we'd still keep the break
token generated (to resume at column content after the spanner(s)), and
this in turn would cause trouble when calucalting the fragmentainer
index in NGBlockNode::AddColumnResult() (we'd essentially never add a
fragment at index 0, but jump straight to 1).

We may need to revisit this again in the future, though. Overflow
calculation comes to mind. We'll now create a 1px tall fragmentainer
even inside 0px tall multicol containers. But we can either just prevent
fragmentainers from contributing to overflow (this is not what other
browsers do, though), or actually make such fragmentainers 0px tall
(they become 1px because the spec says that fragmentainers may not be
shorter than that, but we might get away with it anyway).

Add a DCHECK in LayoutBox::AddLayoutResult() to assert that we don't
mess up the index (like we used to, which in turn made us keep fragments
associated with deleted layout objects).

Quite a few unit tests had to be updated because of this. I changed some
of them slightly, to give the new empty fragmentainers a nicer width
that they'd otherwise get.

Bug: 1105758
Change-Id: I44e1b93dea4cd5e0c5f7944798e2336530a6d1a4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2346389
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#796859}