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)
commitfc5e340d65664a9bb077f3526c9111f1d94e41fe
tree9448f35a5ba786d3e36c3a95cd5fc4cb398c7fcb
parenta6885f511bcb23f6316ffc69beeb6158ebd469e7
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.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@173344 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/page/FrameView.cpp