Doing a navigation on a non-opaque WKWebView can result in an empty layer tree
authortimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 6 Sep 2014 00:14:15 +0000 (00:14 +0000)
committertimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 6 Sep 2014 00:14:15 +0000 (00:14 +0000)
https://bugs.webkit.org/show_bug.cgi?id=136590
<rdar://problem/18234000>

Reviewed by Simon Fraser.

* page/FrameView.cpp:
(WebCore::FrameView::setTransparent):
Avoid scheduling a compositing layer update if the RenderView isn't the
one associated with this FrameView. This can happen during a navigation,
before the new Document (and RenderView) is swapped in. This is particularly
bad in the case of setTransparent because it is called from Frame::createView,
which is right in the middle of that transition window. If we let the compositing
layer update go ahead, it can end up detaching the new Document's layer tree,
and we have no mechanism that would cause it to reattach.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@173344 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WebCore/ChangeLog
Source/WebCore/page/FrameView.cpp

index d883169fca0635ee6ca4dc933463dae7229eed37..9b0b02a8c41f97f788411af606f4c02a477c14b9 100644 (file)
@@ -1,3 +1,21 @@
+2014-09-05  Tim Horton  <timothy_horton@apple.com>
+
+        Doing a navigation on a non-opaque WKWebView can result in an empty layer tree
+        https://bugs.webkit.org/show_bug.cgi?id=136590
+        <rdar://problem/18234000>
+
+        Reviewed by Simon Fraser.
+
+        * page/FrameView.cpp:
+        (WebCore::FrameView::setTransparent):
+        Avoid scheduling a compositing layer update if the RenderView isn't the
+        one associated with this FrameView. This can happen during a navigation,
+        before the new Document (and RenderView) is swapped in. This is particularly
+        bad in the case of setTransparent because it is called from Frame::createView,
+        which is right in the middle of that transition window. If we let the compositing
+        layer update go ahead, it can end up detaching the new Document's layer tree,
+        and we have no mechanism that would cause it to reattach.
+
 2014-09-05  Enrica Casucci  <enrica@apple.com>
 
         Remove PLATFORM(IOS) from WebCore/editing (Part 3).
 2014-09-05  Enrica Casucci  <enrica@apple.com>
 
         Remove PLATFORM(IOS) from WebCore/editing (Part 3).
index 4f38eab2cfbebc36aac70a12b68e2404c50a21e4..8cf16b85c54fe287f50f8f550d0a11fa420b2ef4 100644 (file)
@@ -2582,6 +2582,13 @@ void FrameView::setTransparent(bool isTransparent)
     if (!renderView)
         return;
 
     if (!renderView)
         return;
 
+    // setTransparent can be called in the window between FrameView initialization
+    // and switching in the new Document; this means that the RenderView that we
+    // retrieve is actually attached to the previous Document, which is going away,
+    // and must not update compositing layers.
+    if (&renderView->frameView() != this)
+        return;
+
     RenderLayerCompositor& compositor = renderView->compositor();
     compositor.setCompositingLayersNeedRebuild();
     compositor.scheduleCompositingLayerUpdate();
     RenderLayerCompositor& compositor = renderView->compositor();
     compositor.setCompositingLayersNeedRebuild();
     compositor.scheduleCompositingLayerUpdate();