Fix painting order of atomic inline stacking containers#30458
Fix painting order of atomic inline stacking containers#30458jdm merged 11 commits intoservo:masterfrom
Conversation
|
@bors-servo try=wpt-2020 |
|
🔨 Triggering try run (#6381205600) with platform=linux and layout=2020 |
|
Test results for linux-wpt-layout-2020 from try job (#6381205600): Flaky unexpected result (11)
Stable unexpected results that are known to be intermittent (18)
Stable unexpected results (10)
|
|
|
Loirooriol
left a comment
There was a problem hiding this comment.
The problem is that for
<div style="width: 100px; height: 100px; background: red; position: relative;">
<div style="display: inline-block; width: 100px; height: 100px; background: green;"></div>
</div>
this paints the inline-block behind its parent due to (SCT::PseudoAtomicInline, _) => Ordering::Less.
|
It looks like we only prevent float stacking containers from being stolen by the parent stacking context, Both real stacking contexts and positioned stacking containers should be stolen, while float stacking containers and atomic inline stacking containers should be left in the new stacking container. I also noticed that we fail to interleave atomic inline stacking containers with fragments: <div style="display: inline-block; width: 1em; height: 1em;">
<div style="background: red; width: 5em; height: 1em;">— FAIL</div>
</div> <span style="background: white;">PASS</span>f76bf3c fixes interleaving with fragments and prevents atomic inline stacking containers from being stolen, but it erroneously prevents positioned stacking containers from being stolen. 522f298 fixes that. |
|
@bors-servo try=wpt-2020 |
|
🔨 Triggering try run (#6388844223) with platform=linux and layout=2020 |
|
|
ad5e309 to
f76bf3c
Compare
|
@bors-servo try=wpt-2020 |
|
🔨 Triggering try run (#6389139624) with platform=linux and layout=2020 |
|
|
|
@bors-servo try=wpt-2020 |
|
🔨 Triggering try run (#6390243047) with platform=linux and layout=2020 |
|
|
fc7ef9a to
34e430b
Compare
|
@bors-servo try=wpt-2020 |
|
🔨 Triggering try run (#6390648595) with platform=linux and layout=2020 |
34e430b to
522f298
Compare
|
@bors-servo try=wpt-2020 |
|
🔨 Triggering try run (#6390684506) with platform=linux and layout=2020 |
|
✨ Try run (#6391690877) succeeded. |
|
8e60b20 + eba315d + 315b548 rework the naming and docs as follows:
I considered referring to things that can be either a stacking context or stacking container as a “stacking cont” (and renaming symbols accordingly), but the result looked too eccentric. The approach I went with still invents terminology (“real”), but I think that’s unavoidable with the current spec. |
|
@bors-servo try=wpt-2020 |
|
🔨 Triggering try run (#6416742881) with platform=linux and layout=2020 |
|
Test results for linux-wpt-layout-2020 from try job (#6416742881): Flaky unexpected result (18)
Stable unexpected results that are known to be intermittent (18)
|
|
✨ Try run (#6416742881) succeeded. |
mrobinson
left a comment
There was a problem hiding this comment.
Thanks for the iterations on this. This is looking good to me. There is only one thing that I think should be changed before landing and that is avoiding a panic when having issues painting the root canvas background.


When we add children to a stacking context, sort the stacking context, and build a display list for it, we partition our children into fragments, float stacking containers, and all other stacking containers and stacking contexts. Then we partition the latter into those with negative ‘z-index’ and those with non-negative (or auto) ‘z-index’.
This is incorrect per css-position-4 #painting-order and w3c/csswg-drafts#2717. Atomic inline stacking containers should never be stolen by the parent stacking context, and they should be painted together with fragments in tree order.
This patch fixes that by:
We also add warnings for the assertions in build_canvas_background_display_list when debug assertions are not enabled, and add debug logging to show the stacking context tree in painting order under
-Z dump-stacking-context-tree.Here are the results and debug logs for the original test cases:
test case in #30428 (description)
test case in #30428 (comment)
test case in #30458 (comment)
test case in #30474 (description)
./mach build -ddoes not report any errors./mach test-tidydoes not report any errors‘transform-style: preserve-3d’ does not work #30474