commit 78d3bcd3bbe1d6989d4abed6b038546e07091520
author Morten Stenshorne <mstensho@chromium.org> Fri Apr 26 08:14:45 2024
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Fri Apr 26 09:30:55 2024
tree 186353a1770e535c3ecf2ba0f9604ae9a46f1c01
parent 02b833cb476b5d6afd93a183ea3811c85b1b0d19

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" the new PaginationState class, and destroyed when
the pagination layout fragment tree is no longer needed.

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/c/chromium/src/+/5453623
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292911}