Closed Bug 1645063 Opened 5 years ago Closed 5 years ago

[wpt-sync] Sync PR 24108 - [LayoutNG] Better support for parallel flows in block fragmentation.

Categories

(Core :: Layout, task, P4)

task

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox79 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 24108 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/24108
Details from upstream follow.

Morten Stenshorne <mstensho@chromium.org> wrote:

[LayoutNG] Better support for parallel flows in block fragmentation.

To determine whether we should stop layout of a fragment or not, it's
not enough to check if we're at the end of a fragmentainer. Having 0px
left doesn't mean that we're done. Other 0px tall fragments may fit
there, and if there's a negative margin, we may also move upwards. A
parent node might also have parallel flows inside, which doesn't affect
where the parent node should break.

This CL introduces a new flag to block break tokens which is used to
tell whether we're at the block-end of a node. If there are child breaks
inside of a node, the node may fragment and continue in the next
fragmentainer, even if the node has got all the space that it can use.
When we're in this state, the contents of the node will be in a parallel
flow [1], which means that siblings of the node may be laid out into the
same fragmentainer, even though the node broke. This bit of information
will help us determine whether or not to break inside the parent of a
node that broke.

[1] https://www.w3.org/TR/css-break-3/#parallel-flows

In the box fragment builder, tone down and rename DidBreak() to
DidBreakSelf(). This should now only be true if we decide to break
inside a box because of the box itself (e.g. due to its block-size),
regardless of its children. There's some work remaining here (it's used
more often that we'd like), expressed as TODOs.

Also remove a state flag from the block layout algorithm, and store all
we need in the fragment builder instead. This should also benefit other
layout algorithms that want to support block fragmentation.

Bug: 829028
Change-Id: I3ef122c27fa2b404bb698ae68b5a379d617a336f
Reviewed-on: https://chromium-review.googlesource.com/2238193
WPT-Export-Revision: dc9ca738b481c67c39327e64735ee4c4ced7d6e3

Component: web-platform-tests → Layout
Product: Testing → Core

CI Results

Ran 0 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 7 tests

Status Summary

Firefox

PASS: 7

Chrome

PASS: 5
FAIL: 2

Safari

PASS: 5
FAIL: 2

Links

GitHub PR Head
GitHub PR Base

Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5ec19281cce9 [wpt PR 24108] - [LayoutNG] Better support for parallel flows in block fragmentation., a=testonly
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
You need to log in before you can comment on or make changes to this bug.