Fix rendering regression for out-of-process iframes

Source/web/WebLocalFrameImpl.cpp

Index: Source/web/WebLocalFrameImpl.cpp
diff --git a/Source/web/WebLocalFrameImpl.cpp b/Source/web/WebLocalFrameImpl.cpp
index 9da6d1bc717b6c2687451c6a1db43f858cdc1764..094fb606fce6fbf1b869d1760cf4c8720958d351 100644
--- a/Source/web/WebLocalFrameImpl.cpp
+++ b/Source/web/WebLocalFrameImpl.cpp
@@ -556,6 +556,7 @@ void WebLocalFrameImpl::setRemoteWebLayer(WebLayer* webLayer)
     // FIXME: This should be moved to WebRemoteFrame.
     ASSERT(frame()->deprecatedLocalOwner());
     frame()->deprecatedLocalOwner()->setNeedsCompositingUpdate();
+    frame()->ownerRenderer()->layer()->updateSelfPaintingLayer();

[ojan, 2014/06/13 21:29:09]

Is the frame guaranteed to have a renderer at this point?

[kenrb, 2014/06/16 15:43:38]

I was thinking yes, but now that you ask I am not certain. The frame has to be
attached to the DOM and have been navigated, which I think means must have had
attach() called at some point, but might there possibly be race conditions if it
has its renderer later destroyed?

[ojan, 2014/06/17 16:42:11]

Yeah, I'm not sure. You could put in an ASSERT(frame()->ownerRenderer()) and see
if any layout tests or webkit_unit_tests hit it.

 }
 
 void WebLocalFrameImpl::setPermissionClient(WebPermissionClient* permissionClient)