Send initializeChildFrame from RenderFrameProxy instead of WebLocalFrame

Send initializeChildFrame from RenderFrameProxy instead of WebLocalFrame.

This will clean up the hack introduced in https://codereview.chromium.org/591503003/ to allow out-of-process iframes to paint.

This CL is part 1 of 3.  It adds an initializeFromFrame() to WebRemoteFrame to do the work that setIsRemote() used to do.  initializeFromFrame is intended for transferring relevant properties to a remote frame that is about to replace the current frame.  Because this is specific to a local-to-remote frame transition, this is done with a new method rather than in WebFrame::swap().

This will be followed by Chromium-side Part 2 (https://codereview.chromium.org/592263002) which will replace RenderFrameImpl::OnSwapOut's call to setIsRemote with a call to initializeFromFrame.  Another blink-side CL will then remove WebLocalFrame::setIsRemote.

BUG=416102, 407160
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=182645

[alexmos, 2014-09-23 18:21:15]

alexmos@chromium.org changed reviewers:
+ dcheng@chromium.org

[alexmos, 2014-09-23 18:30:03]

Daniel, could you please take a look?  This is an attempt to  clean up
setIsRemote and Charlie's earlier OOPI painting hack.

[dcheng, 2014-09-23 18:57:07]

The approach looks reasonable. From an API standpoint, I wonder if it might make
more sense to move this method to WebRemoteFrame and call it initialize or
initializeAsChild, taking a WebLocalFrame* as the parameter. Would we ever have
a situation where we'd call this on a top-level frame?

[alexmos, 2014-09-23 22:00:50]

On 2014/09/23 18:57:07, dcheng wrote:
> The approach looks reasonable. From an API standpoint, I wonder if it might
make
> more sense to move this method to WebRemoteFrame and call it initialize or
> initializeAsChild, taking a WebLocalFrame* as the parameter. 

Done.  I called it WebRemoteFrame::initializeFromFrame; let me know if that's
ok.

> Would we ever have a situation where we'd call this on a top-level frame?

It shouldn't happen (we discussed this offline).

[dcheng, 2014-09-24 23:31:19]

LGTM with one nit.

Also, please update the CL description to mention why we're doing this in a
separate function than trying to combine it into swap (this is specific to a
local to remote transition).

https://codereview.chromium.org/591413004/diff/20001/Source/web/tests/FrameTe...
File Source/web/tests/FrameTestHelpers.h (right):

https://codereview.chromium.org/591413004/diff/20001/Source/web/tests/FrameTe...
Source/web/tests/FrameTestHelpers.h:127: float scaleFactor) { }
This shouldn't be necessary. We usually give new WebFooClient methods an empty
body to prevent this.

[alexmos, 2014-09-25 00:19:01]

On 2014/09/24 23:31:19, dcheng wrote:
> LGTM with one nit.
> 
> Also, please update the CL description to mention why we're doing this in a
> separate function than trying to combine it into swap (this is specific to a
> local to remote transition).

Done.
 
>
https://codereview.chromium.org/591413004/diff/20001/Source/web/tests/FrameTe...
> File Source/web/tests/FrameTestHelpers.h (right):
> 
>
https://codereview.chromium.org/591413004/diff/20001/Source/web/tests/FrameTe...
> Source/web/tests/FrameTestHelpers.h:127: float scaleFactor) { }
> This shouldn't be necessary. We usually give new WebFooClient methods an empty
> body to prevent this.

Done.

[alexmos, 2014-09-25 00:37:54]

alexmos@chromium.org changed reviewers:
+ dglazkov@chromium.org

[alexmos, 2014-09-25 00:53:00]

Hi Dimitri, could you please review this CL?  The goal is to clean up how the
initializeChildFrame IPC message gets sent.
Thanks!
Alex

[dglazkov, 2014-09-25 00:57:31]

lgtm

[alexmos, 2014-09-25 01:23:10]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2014-09-25 01:23:44]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/591413004/40001

[commit-bot: I haz the power, 2014-09-25 02:09:27]

Committed patchset #3 (id:40001) as 182645