| Summary: | Wrong layer order with negative z-index and will-change: transform | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Dartess <dartess> | ||||
| Component: | Compositing | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | Hironori.Fujii, rbuis, simon.fraser, webkit-bug-importer, zalan | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari 13 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
|
Description
Dartess
2020-07-21 06:47:58 PDT
I can reproduce. I'm a bit surprised we get this wrong. This happens because when we see a negative z-index child, we make its stacking context layer compositing eagerly:
for (auto* childLayer : layer.negativeZOrderLayers()) {
computeCompositingRequirements(&layer, *childLayer, overlapMap, currentState, backingSharingState, anyDescendantHas3DTransform);
// If we have to make a layer for this child, make one now so we can have a contents layer
// (since we need to ensure that the -ve z-order child renders underneath our contents).
if (!willBeComposited && currentState.subtreeIsCompositing) {
layer.setIndirectCompositingReason(IndirectCompositingReason::BackgroundLayer);
layerWillComposite();
}
}
but this messes up the overlap map, so the second negative z-index child doesn't see the rects from the first one.
Fixing https://bugs.webkit.org/show_bug.cgi?id=217154 also seems to fix this. This seems fixed these days. |