[wpt-sync] Sync PR 47160 - Prevent break between cloned box decoration and 1st child fragment.
Categories
(Core :: Layout, task, P4)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox130 | --- | fixed |
People
(Reporter: wpt-sync, Unassigned)
References
()
Details
(Whiteboard: [wptsync downstream])
Sync web-platform-tests PR 47160 into mozilla-central (this bug is closed when the sync is complete).
PR: https://github.com/web-platform-tests/wpt/pull/47160
Details from upstream follow.
Morten Stenshorne <mstensho@chromium.org> wrote:
Prevent break between cloned box decoration and 1st child fragment.
This would cause an infinite loop, due to a last-resort break being
inserted before a tall and unbreakable first-child-fragment over and
over again. Last-resort breaks are questionable in general, but in the
case of cloned box decorations, there's really no question: They must be
avoided! Avoid this by adjusting the fragmentainer block-offset more
consistently when cloned decorations are used. We previously did this
for child constraint spaces, but the fragment builder (the parent of
such constraint spaces) that establishes cloned decorations really also
needs to do this.Add blink::FragmentationOffset() that takes a builder argument, rather
than using ConstraintSpace::FragmentainerOffset() directly, so that we
can pay attention to cloned block-start decorations. Also add a
FragmentationOffsetForChildren() convenience function to
LayoutAlgorithm.This is all pretty simple, except when it comes from floats, which has
no access to the parent fragment builder (they don't even know if it's
an inline or block layout algorithm - and they really don't want to
know, either). UnpositionedFloat now needs to know the fragmentainer
offset (it already knew the fragmentainer block size). The fragmentainer
offset is meaningless unless inside block fragmentation, and there even
used to be a DCHECK in ConstraintSpace::FragmentainerOffset() for it.
Just remove it, rather than worrying about this at every call site.Also flip is_for_children to false in call to FragmentainerSpaceLeft()
in SetupFragmentBuilderForFragmentation(). This is correct, although it
doesn't matter much with the way the code is right now, since we haven't
yet told the builder whether block-end decorations should be cloned at
this point. There are tests for this situation (when the remainder of
the node fits in the current fragmentainer, and block-end decorations
should therefore not be cloned, but behave as regular block-end
decorations), such as css/css-break/box-decoration-break-clone-002.htmlBug: 40415661
Change-Id: I2f1d596fa638435b5f6f66dd5ae234fb48e26475
Reviewed-on: https://chromium-review.googlesource.com/5713911
WPT-Export-Revision: 93f0d4dcd8c4b60a97e8a950e9a03bca6dc2b43e
|
Assignee | |
Updated•1 year ago
|
|
|
Assignee | |
Comment 1•1 year ago
|
||
|
|
Assignee | |
Comment 2•1 year ago
|
||
|
|
Assignee | |
Comment 3•1 year ago
|
||
CI Results
Ran 9 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI
Total 3 tests
Status Summary
Firefox
PASS: 3
Chrome
FAIL: 3
Safari
PASS: 2
FAIL: 1
Links
|
||
Comment 5•1 year ago
|
||
| bugherder | ||
Description
•