Closed Bug 1718778 Opened 1 year ago Closed 1 year ago

[wpt-sync] Sync PR 29543 - PrePaint: LayoutObject traversal with LayoutNG fragment lookups.

Categories

(Core :: Layout, task, P4)

task

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox92 --- fixed

People

(Reporter: mozilla.org, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [wptsync downstream])

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

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

b'Morten Stenshorne <mstensho@chromium.org>' wrote:

PrePaint: LayoutObject traversal with LayoutNG fragment lookups.

Almost completely move away from fragment traversal in pre-paint.
Instead do LayoutObject traversal accompanied by a corresponding
NGPhysicalBoxFragment when possible. This means that we'll keep track of
the fragment of the parent LayoutObject at any given time, and, when
entering a child LayoutObject, we'll search the that fragment for a
child fragment (or child fragment item) representing a child
LayoutObject. If we don't find the child, it means that it doesn't exist
in the current fragmentainer.

One piece of complexity here is out-of-flow positioned elements. Since
we're traversing the LayoutObject tree, and keep track of the fragment
of the parent LayoutObject, for OOFs, we also need to keep track of the
ancestor fragments that may contain absolutely or fixed positioned
descendants, and search them, rather than the parent fragment, when
looking for OOFs. We also need to make paint offset adjustments when
entering OOFs, since OOFs are direct children of a fragmentainer, rather
than a child of their actual containing block.

There are still a few cases where it's just too hard to avoid fragment
traversal, though:

  1. OOF fragments with missing containing block fragments. This happens
    when an OOF inside block fragmentation overflows its actual containing
    block, and occurs in fragmentainers where the containing block doesn't
    occur.

  2. Fragmented floats inside inline formatting contexts, when the float
    occurs in fragmentainers where some of its ancestors don't.

  3. Column spanners are always entered directly from the ancestor
    multicol container.

When we fall back to fragment traversal like this, we'll also miss any
paint effects that should be caused by the missing ancestors. The new
test external/wpt/css/css-break/transform-009.html is failing because of
this. See crbug.com/1224888 . We might want to revisit this later if
important enough, but it will require large changes to how we lay out
OOFs in block fragmentation.

This CL fixes as many as one existing test. Added a few new ones that
previously didn't pass (except for the one mentioned above). This CL
fixes a few things:

  1. Apply paint effects caused by parents not in the containing block
    chain (e.g. on an abspos inside opacity inside relpos).

  2. Handle transforms correctly for OOFs inside multicol.

  3. Clear paint invalidation flags for text and non-atomic inlines, so
    that if someone dirties them, we'll actually mark the tree properly, and
    recalculate paint properties and invalidate for paint as necessary.

virtual/layout_ng_fragment_traversal/external/wpt/css/CSS2/positioning/
toogle-abspos-on-relpos-inline-child.html is now failing. See
crbug.com/1225304

Remove NGFragmentChildIterator, since this was only used as a helper for
fragment traversal in pre-paint. It helped us access incoming break
tokens very easily. We cannot use it for LayoutObject traversal. We
still need the incoming break token in a couple of relatively rare
cases, and we'll just find it manually there. This isn't exactly cheap,
but I believe that, at some point in the future, we won't need incoming
break tokens at all during painting (only during layout).

As part of reducing the need for incoming break tokens, we'll no longer
use the "flow thread offset" as an ID in FragmentData in NG (in fact, we
were abusing this field by storing consumed block-size instead of flow
thread offset). Instead we'll use the fragmentainer index, which is
easier and cheaper to obtain. PaintInfo will now map from
NGPhysicalBoxFragment to FragmentData in more cases than before, rather
than comparing fragment IDs. The only case in NG where we need to map
using the fragment ID is for self-painting non-atomic inlines (which
don't store a vector of physical fragments in the layout object).

Bug: 1043787
Change-Id: I63f5b9bc07d45770a728f6d125baf02800863aa5
Reviewed-on: https://chromium-review.googlesource.com/2996982
WPT-Export-Revision: c4a4e3d75f35bbaca97c58580da99cdbd66c6ca8

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

CI Results

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

Total 8 tests

Status Summary

Firefox

PASS: 3[Gecko-android-em-7.0-x86_64-qr-debug-geckoview, Gecko-linux1804-64-qr-debug, Gecko-windows10-64-qr-debug] 4[Gecko-android-em-7.0-x86_64-debug-geckoview, Gecko-android-em-7.0-x86_64-opt-geckoview, Gecko-android-em-7.0-x86_64-qr-opt-geckoview, Gecko-linux1804-64-debug, Gecko-linux1804-64-opt, Gecko-linux1804-64-qr-opt, Gecko-linux1804-64-tsan-opt, Gecko-windows10-32-qr-debug, Gecko-windows10-32-qr-opt, Gecko-windows10-64-qr-opt, GitHub]
FAIL: 4[Gecko-android-em-7.0-x86_64-debug-geckoview, Gecko-android-em-7.0-x86_64-opt-geckoview, Gecko-android-em-7.0-x86_64-qr-opt-geckoview, Gecko-linux1804-64-debug, Gecko-linux1804-64-opt, Gecko-linux1804-64-qr-opt, Gecko-linux1804-64-tsan-opt, Gecko-windows10-32-qr-debug, Gecko-windows10-32-qr-opt, Gecko-windows10-64-qr-opt, GitHub] 5[Gecko-android-em-7.0-x86_64-qr-debug-geckoview, Gecko-linux1804-64-qr-debug, Gecko-windows10-64-qr-debug]

Chrome

PASS: 4
FAIL: 4

Safari

PASS: 4
FAIL: 4

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

Firefox-only Failures

/css/css-break/abspos-in-opacity-001.html: FAIL

New Tests That Don't Pass

/css/css-break/abspos-in-opacity-001.html: FAIL (Chrome: PASS, Safari: PASS)
/css/css-break/contain-strict-with-opacity-and-oof.html: FAIL [Gecko-android-em-7.0-x86_64-qr-debug-geckoview, Gecko-linux1804-64-qr-debug, Gecko-windows10-64-qr-debug], PASS [Gecko-android-em-7.0-x86_64-debug-geckoview, Gecko-android-em-7.0-x86_64-opt-geckoview, Gecko-android-em-7.0-x86_64-qr-opt-geckoview, Gecko-linux1804-64-debug, Gecko-linux1804-64-opt, Gecko-linux1804-64-qr-opt, Gecko-linux1804-64-tsan-opt, Gecko-windows10-32-qr-debug, Gecko-windows10-32-qr-opt, Gecko-windows10-64-qr-opt, GitHub] (Chrome: PASS, Safari: PASS)
/css/css-break/transform-008.html: FAIL (Chrome: FAIL, Safari: FAIL)
/css/css-break/transform-009.html: FAIL (Chrome: FAIL, Safari: FAIL)
/css/css-multicol/spanner-in-opacity.html: FAIL (Chrome: FAIL, Safari: FAIL)

Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/296736f90547
[wpt PR 29543] - PrePaint: LayoutObject traversal with LayoutNG fragment lookups., a=testonly
https://hg.mozilla.org/integration/autoland/rev/b17610925ef9
[wpt PR 29543] - Update wpt metadata, a=testonly
Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b37f2b8cbccc
[wpt PR 29543] - PrePaint: LayoutObject traversal with LayoutNG fragment lookups., a=testonly
https://hg.mozilla.org/integration/autoland/rev/6f611bde040e
[wpt PR 29543] - Update wpt metadata, a=testonly
You need to log in before you can comment on or make changes to this bug.