Closed Bug 1891716 Opened 7 months ago Closed 7 months ago

[wpt-sync] Sync PR 45736 - Plumbing for new pagination fragment structure.

Categories

(Core :: Layout, task, P4)

Product:
Core
Component:
Layout
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
127 Branch
Tracking Flags:
Tracking Status
firefox127 --- fixed

People

(Reporter: wpt-sync, Unassigned)

References

(
URL
)

Details

(Whiteboard: [wptsync downstream])

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

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

Morten Stenshorne <mstensho@chromium.org> wrote:

Plumbing for new pagination fragment structure.

Previously each page would be represented by a single page fragment
(fragmentainer) with all the document contents inside. However, in order
to support @page properties and margins, we need something more
advanced.

Split the page fragment into three fragments: page container, page
border box, and page area. A page area will always be a child of a page
border box, which in turn will always be a child of a page container.
Page containers are direct children of the LayoutView fragment.

A page container will represent the containing block of a page. It
represents the entire sheet of paper (when printing one page per sheet).

A page border box is simply the border box size of a page. It will be
responsible for painting any effects caused by @page properties - except
the background, which should cover the entire page container.

A page area is a fragmentainer. It contains a portion of the fragmented
document.

See https://drafts.csswg.org/css-page-3/#page-model

For now, all these fragments have the same size, since margins are still
handled on the outside of Blink (e.g. printing::PrintRenderFrameHelper).
This will change in upcoming CLs.

In order for these new fragments to be able to paint anything, they need
a BlockNode (LayoutObject). A BlockNode will also be required in order
to resolve lengths in the standard way, using length_utils (upcoming
CL). These layout objects will not be attached to the layout tree (i.e.
under the LayoutView), since we cannot mutate the layout tree during
layout, and besides they wouldn't serve any purpose there. Such layout
objects are owned by the respective page fragments, and destroyed when
such a fragment gets garbage-collected.

The page area serves as a boundary between the document's contents and
the (non-DOM) page boxes. Therefore, don't propagate info from a page
area fragment to its parent (page border box) fragment. They will
eventually exist in different coordinate systems. OutOfFlowLayoutPart
needs to be updated because of this. Out-of-flow layout needs to take
place when we have returned to the root algorithm. OutOfFlowLayoutPart
now needs to grab any pending OOFs manually from each fragmentainer
(page area inside page border box inside page container), and lay them
out.

No behavior changes intended, unless PageMarginBoxes are enabled.
Keep on reading. We're almost done.

When PageMarginBoxes are enabled, any @page properties that are to apply
in a page context according to the spec may now have paint effects.
@page borders for instance. Add a test for that. Note that layout still
doesn't position the page area correctly within the page border box,
which is why the text in the test is centered (if it were positioned at
0,0, it would have been painted over the border). StyleResolver needs to
be adjusted, to make sure that initial style is returned if the page
context is inside a display:none subtree (an existing test would fail if
not). If computed style is to be generated, on the other hand, make sure
that it becomes display:block.

Bug: 40286153
Change-Id: I59b088bcdde3d95782358809f2377cd61e6a1f73

Reviewed-on: https://chromium-review.googlesource.com/5453623
WPT-Export-Revision: 340f854f0c6c065addef477a5abe02d39744d11b

Component: web-platform-tests → Layout
Product: Testing → Core
Whiteboard: [wptsync downstream] → [wptsync downstream error]
Whiteboard: [wptsync downstream error] → [wptsync downstream]

CI Results

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

Total 1 tests

Status Summary

Firefox

FAIL: 1

Chrome

FAIL: 1

Links

GitHub PR Head
GitHub PR Base

Details

New Tests That Don't Pass

Pushed by wptsync@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/537b3abeb998 [wpt PR 45736] - Plumbing for new pagination fragment structure., a=testonly https://hg.mozilla.org/integration/autoland/rev/f0d87682a059 [wpt PR 45736] - Update wpt metadata, a=testonly

https://hg.mozilla.org/mozilla-central/rev/537b3abeb998
https://hg.mozilla.org/mozilla-central/rev/f0d87682a059

Status: NEW → RESOLVED
Closed: 7 months ago
status-firefox127: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch
You need to log in before you can comment on or make changes to this bug.