Bug 214594 - Wrong layer order with negative z-index and will-change: transform
Summary: Wrong layer order with negative z-index and will-change: transform
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Compositing (show other bugs)
Version: Safari 13
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-07-21 06:47 PDT by Dartess
Modified: 2021-09-01 00:39 PDT (History)
5 users (show)

See Also:


Attachments
demo (1.08 KB, text/html)
2020-07-21 06:47 PDT, Dartess
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dartess 2020-07-21 06:47:58 PDT
Created attachment 404817 [details]
demo

live demo (also in attach): https://codepen.io/dartess/pen/bGEOJwM

when items has negative z-index AND has will-change: transform safari broke z-index order.
Comment 1 Radar WebKit Bug Importer 2020-07-21 18:43:47 PDT
<rdar://problem/65914326>
Comment 2 Simon Fraser (smfr) 2020-07-21 20:55:49 PDT
I can reproduce. I'm a bit surprised we get this wrong.
Comment 3 Simon Fraser (smfr) 2020-07-29 16:22:33 PDT
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.
Comment 4 Rob Buis 2021-09-01 00:39:11 PDT
Fixing https://bugs.webkit.org/show_bug.cgi?id=217154 also seems to fix this.