Bug 1861379 [wpt PR 42778] - Avoid duplicate block-in-inline break tokens., a=testonly
commita62b418143fc69a61acccb51aca8b064ab4b2808
authorBlink WPT Bot <blink-w3c-test-autoroller@chromium.org>
Wed, 8 Nov 2023 08:29:09 +0000 (8 08:29 +0000)
committermoz-wptsync-bot <wptsync@mozilla.com>
Sun, 19 Nov 2023 15:18:58 +0000 (19 15:18 +0000)
tree6d038abd600868a237e09e22284c02407b363013
parentcf9f1f50fe264d786670a47e7790ab3f6479d710
Bug 1861379 [wpt PR 42778] - Avoid duplicate block-in-inline break tokens., a=testonly

Automatic update from web-platform-tests
Avoid duplicate block-in-inline break tokens. (#42778)

Regardless of whether the break inside a block-in-inline was to be
resumed in a parallel flow or not, we'd also include it as a break token
in the same flow.

This was usually harmless, since any next line in the same fragmentainer
would typically not be a block-in-inline, since all consecutive blocks
inside inlines are put inside the same block-in-inline wrapper during
box generation.

However, there are ways to end up with adjacent block-in-inline
wrappers: If a block that previously wasn't inflow becomes inflow
(change from float:left to float:none, for instance), a new wrapper is
created around the now-inflow block, even if there's already an adjacent
wrapper there for an adjacent block.

  <span>
    <div id="first" style="float:left;"></div>
    <div id="second"></div>
  </span>

This generates a box tree like this:

  LayoutInline           SPAN
    LayoutNGBlockFlow    (floating) DIV #first
    LayoutNGBlockFlow    (anonymous)
      LayoutNGBlockFlow  DIV #second

If we (after initial layout) change #first to float:none, we end up with
this:

  LayoutInline           SPAN
    LayoutNGBlockFlow    (anonymous)
      LayoutNGBlockFlow  DIV #first
    LayoutNGBlockFlow    (anonymous)
      LayoutNGBlockFlow  DIV #second

The fix is to make sure that we only create one break token for a
fragmented block wrapper. Move the code that examines the outgoing
block-in-inline break token a bit further up, to eliminate the need for
LineInfo::BlockInInlineBreakToken(), and to keep things a bit more
tightly together. Add a DCHECK to LineBreaker::HandleBlockInInline(),
which would have failed without this fix.

Bug: 1495515
Change-Id: I6d019b8c2e6c03046e122fecce76e044f3aeabb3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4973967
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1216882}

Co-authored-by: Morten Stenshorne <mstensho@chromium.org>
--

wpt-commits: f78621256f99c77ef9dbced0301c1ff25f71abf5
wpt-pr: 42778
testing/web-platform/tests/css/css-break/block-in-inline-010-crash.html [new file with mode: 0644]
testing/web-platform/tests/css/css-break/block-in-inline-011.html [new file with mode: 0644]