[wpt-sync] Sync PR 42189 - Never break before a float resumed after a break.
Categories
(Core :: Layout, task, P4)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox120 | --- | fixed |
People
(Reporter: wpt-sync, Unassigned)
References
()
Details
(Whiteboard: [wptsync downstream])
Sync web-platform-tests PR 42189 into mozilla-central (this bug is closed when the sync is complete).
PR: https://github.com/web-platform-tests/wpt/pull/42189
Details from upstream follow.
Morten Stenshorne <mstensho@chromium.org> wrote:
Never break before a float resumed after a break.
Always process all incoming inline break tokens that establish a
parallel flow for a fragmented float or overflowed block-in-inline.The orphans implementation works so that if we run out of space in a
fragmentainer, we'll still keep on laying out a few more lines, to
figure out if we should break further up (rather than exactly where we
run out of space), in order to honor widows. We count the number of
lines laid out. The fix is to make sure that inline break tokens that
just contain a resumed float or block-in-inline (in a parallel flow)
leave this counter alone. Otherwise we risk breaking before even getting
around to resuming the block node inside, which means that it wouldn't
be added to the fragment tree at all.Add DCHECKs after layout of a block to make sure that we don't break at
a location where we'll be unable to resume correctly. This also includes
DCHECKing block break tokens, not just inline break tokens. There are no
known issues for block layout ending up in this state, but it would be
equally bad if it happens.This also fixes a correctness issue that was introduced by CL:4874801.
Counting resumed floats as line boxes for orphans / widows consideration
caused us to break prematurely in some cases. If this premature break is
before an actual line box, we get a correctness issue (breaking too
soon). If this premature break is before a resumed float, the fragment
tree would be in a bad state, which could lead to crashes.Add a test for both a crash and the correctness issue.
Bug: 1486252
Change-Id: I764c12e01540f7ceb437fb4aca787c9424ddfa48
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4891832
Reviewed-by: Ian Kilpatrick \<ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne \<mstensho@chromium.org>
Reviewed-by: Koji Ishii \<kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1201849}
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
| Assignee | ||
Comment 2•2 years ago
|
||
CI Results
Ran 9 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 2 tests
Status Summary
Firefox
PASS: 2
Chrome
PASS: 2
Safari
PASS: 2
Links
Comment 4•2 years ago
|
||
| bugherder | ||
Description
•