fast/hidpi/video-controls-in-hidpi.html sometimes asserts in WK1

[Simon Fraser (smfr)]

With the patch from bug 197561, fast/hidpi/video-controls-in-hidpi.html sometimes asserts on EWS (I have not been able to reproduce).

[Simon Fraser (smfr)]

The assertion is:
        ASSERT(!parentClipRect.isInfinite());

[Simon Fraser (smfr)]

This code runs when we have a m_ancestorClippingLayer, and we make one based on the result of RenderLayerCompositor::clippedByAncestor(), which uses:

layer.backgroundClipRect(RenderLayer::ClipRectsContext(computeClipRoot, TemporaryClipRects)).isInfinite()

However, RenderLayerBacking::computeParentGraphicsLayerRect() is doing:

        ShouldRespectOverflowClip shouldRespectOverflowClip = compositedAncestor->isolatesCompositedBlending() ? RespectOverflowClip : IgnoreOverflowClip;
        RenderLayer::ClipRectsContext clipRectsContext(compositedAncestor, TemporaryClipRects, IgnoreOverlayScrollbarSize, shouldRespectOverflowClip);
        LayoutRect parentClipRect = m_owningLayer.backgroundClipRect(clipRectsContext).rect(); // FIXME: Incorrect for CSS regions.

so 'shouldRespectOverflowClip' differs.

[Simon Fraser (smfr)]

*** Bug 197731 has been marked as a duplicate of this bug. ***

[Simon Fraser (smfr)]

That code came from https://trac.webkit.org/changeset/168314/webkit

[Simon Fraser (smfr)]

accessibility/media-element.html also hits this

[Simon Fraser (smfr)]

One thing to note here is that normally we don't have an m_ancestorLayer if our clipping ancestor is a stacking context, but with a composited mix-blend-mode child, RenderLayerCompositor::clippedByAncestor() follows a different code path, and can give us an m_ancestorClippingLayer. I don't know why.

[Simon Fraser (smfr)]

This bug is about maintenance of the isolatesCompositedBlending() bit on RenderLayer vs. the maintenance of m_ancestorClippingLayer.

If compositedAncestor->isolatesCompositedBlending() was true at the last compositing update, we made a m_ancestorClippingLayer. At some point another composited sibling with blending became non-composited, so compositedAncestor->isolatesCompositedBlending() is no longer true but we didn't remove the m_ancestorClippingLayer.

[Simon Fraser (smfr)]

isolatesCompositedBlending depends on both m_hasNotIsolatedCompositedBlendingDescendants and isCSSStackingContext

[Simon Fraser (smfr)]

The fix is something like:

index 15479365f2edf9776a01e4f4e70c792921824975..8532ac6c3acb2df5eb75a5d6b43981d2cc5c4eaa 100644
--- a/Source/WebCore/rendering/RenderLayerCompositor.cpp
+++ b/Source/WebCore/rendering/RenderLayerCompositor.cpp
@@ -1022,8 +1022,13 @@ void RenderLayerCompositor::computeCompositingRequirements(RenderLayer* ancestor
         addToOverlapMap(overlapMap, layer, layerExtent);
 
 #if ENABLE(CSS_COMPOSITING)
+    bool isolatedCompositedBlending = layer.isolatesCompositedBlending();
     layer.setHasNotIsolatedCompositedBlendingDescendants(childState.hasNotIsolatedCompositedBlendingDescendants);
     ASSERT(!layer.hasNotIsolatedCompositedBlendingDescendants() || layer.hasNotIsolatedBlendingDescendants());
+    if (layer.isolatesCompositedBlending() != isolatedCompositedBlending) {
+        // isolatedCompositedBlending affects the answer to clippedByAncestor().
+        layer.setChildrenNeedCompositingGeometryUpdate();
+    }
 #endif
     // Now check for reasons to become composited that depend on the state of descendant layers.
     RenderLayer::IndirectCompositingReason indirectCompositingReason;

[Simon Fraser (smfr)]

Created attachment 369491 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/50621407>

[WebKit Commit Bot]

Comment on attachment 369491 [details]
Patch

Clearing flags on attachment: 369491

Committed r245147: <https://trac.webkit.org/changeset/245147>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.