commit 3f1830341fa1459c67e4c5d5c9a90c97b0ca498c
author Morten Stenshorne <mstensho@chromium.org> Wed Sep 20 22:49:04 2023
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Wed Sep 20 23:08:05 2023
tree 55d31dd51a1ade15f845398d883f70d3ffd5d9d8
parent be778b527a2e58a44aec319d6e5ffad1b02d1876

Correct fragmentation of floats inside inlines.

If layout decided to fragment a float, or break before it, and this
float was inside an inline formatting context, it would "escape" the
inline formatting context for subsequent fragments, and be laid out as a
direct float child of the containing block. This would cause paint and
hit testing issues, because the actual inline ancestors of the float
would have no effect on the float, so that e.g. a SPAN with relative
positioning or opacity would only affect the first fragment of the
float. Furthermore, the fact that we were not keeping the float inside
the inline formatting context could also result in a non-contiguous
FragmentData range for a LayoutInline, and, if this LayoutInline
established a PaintLayer,  we would get confused and fail to paint /
hit-test anything in a after a tall float.

We already had code to propagate float breaks to the containing block
layout algorithm. The fix is to wrap the break tokens of such floats
inside an inline break token, and resume such inline break tokens as
parallel fragmentation flows.

We had code in PrePaint as an attempt to cope with escaping float
fragments, to some extent, which is no longer required, so I removed it.
It should be noted that this did by no means work in all situations. If
a float was a child of a PaintLayer-establishing LayoutInline, PrePaint
would get confused as to which PaintLayer was the containing layer of
the float.

More cleanup is possible after this. For now, added a note to
NGBoxFragmentPainter::PaintFloatingChildren(). We should now be able to
assume non-contiguous ranges of physical fragments that have fragment
items. Previously, a tall and fragmented float could prevent some of the
containing physical fragments from getting items.

Update two unit tests. DumpFragmentTree() unfortunately doesn't dump the
contents of a line box, so now that resumed floats also end up inside
lines, they aren't dumped. This was already the case for the first
fragment of any float in an inline formatting context, but now it also
happens to subsequent fragments.

Bug: 1113185, 1327322
Change-Id: Ie81791892d68ffccd0aec92ee6439de4b03326dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4874801
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1199277}