Plumbing toward transitioning remote frame back to a local frame.

Plumbing toward transitioning remote frame back to a local frame.

Currently, navigating a RemoteFrame "works" in --site-per-process release builds but reliably asserts in debug builds. It "works" by overwriting the RemoteFrame with a LocalFrame and proceeding as though this is a standard local->local transition. This patch breaks that and sets up plumbing to notify the browser process that a RemoteFrame was asked to navigate.

BUG=

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=182795

[Nate Chapin, 2014-09-17 19:42:54]

japhet@chromium.org changed reviewers:
+ abarth@chromium.org, dcheng@chromium.org

[Nate Chapin, 2014-09-17 19:42:54]

https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClient.h
File Source/core/frame/FrameClient.h (right):

https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClien...
Source/core/frame/FrameClient.h:32: virtual void navigate(const
ResourceRequest&, bool shouldReplaceCurrentEntry) { }
Should we create a RemoteFrameClient/RemoteFrameClientImpl abstraction?
RemoteFrameClient is currently defined entirely in Source/web/

[dcheng, 2014-09-17 21:38:25]

https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClient.h
File Source/core/frame/FrameClient.h (right):

https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClien...
Source/core/frame/FrameClient.h:32: virtual void navigate(const
ResourceRequest&, bool shouldReplaceCurrentEntry) { }
On 2014/09/17 19:42:54, Nate Chapin wrote:
> Should we create a RemoteFrameClient/RemoteFrameClientImpl abstraction?
> RemoteFrameClient is currently defined entirely in Source/web/

I think this makes sense. We didn't need it initially, which is the reason it
currently only lives in Source/web

[Nate Chapin, 2014-09-18 17:44:08]

On 2014/09/17 21:38:25, dcheng (OOO) wrote:
>
https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClient.h
> File Source/core/frame/FrameClient.h (right):
> 
>
https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClien...
> Source/core/frame/FrameClient.h:32: virtual void navigate(const
> ResourceRequest&, bool shouldReplaceCurrentEntry) { }
> On 2014/09/17 19:42:54, Nate Chapin wrote:
> > Should we create a RemoteFrameClient/RemoteFrameClientImpl abstraction?
> > RemoteFrameClient is currently defined entirely in Source/web/
> 
> I think this makes sense. We didn't need it initially, which is the reason it
> currently only lives in Source/web

Ok, updated with RemoteFrameClient interface in core/frame/

[Nate Chapin, 2014-09-23 19:46:23]

On 2014/09/18 17:44:08, Nate Chapin wrote:
> On 2014/09/17 21:38:25, dcheng (OOO) wrote:
> >
>
https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClient.h
> > File Source/core/frame/FrameClient.h (right):
> > 
> >
>
https://codereview.chromium.org/573353002/diff/1/Source/core/frame/FrameClien...
> > Source/core/frame/FrameClient.h:32: virtual void navigate(const
> > ResourceRequest&, bool shouldReplaceCurrentEntry) { }
> > On 2014/09/17 19:42:54, Nate Chapin wrote:
> > > Should we create a RemoteFrameClient/RemoteFrameClientImpl abstraction?
> > > RemoteFrameClient is currently defined entirely in Source/web/
> > 
> > I think this makes sense. We didn't need it initially, which is the reason
it
> > currently only lives in Source/web
> 
> Ok, updated with RemoteFrameClient interface in core/frame/

Ping

[dcheng, 2014-09-25 00:21:19]

https://codereview.chromium.org/573353002/diff/40001/Source/core/frame/Frame.h
File Source/core/frame/Frame.h (right):

https://codereview.chromium.org/573353002/diff/40001/Source/core/frame/Frame....
Source/core/frame/Frame.h:34: #include "platform/weborigin/Referrer.h"
Do we prefer to forward declare in this case to minimize the amount of #includes
in headers?

https://codereview.chromium.org/573353002/diff/40001/public/web/WebRemoteFram...
File public/web/WebRemoteFrameClient.h (right):

https://codereview.chromium.org/573353002/diff/40001/public/web/WebRemoteFram...
public/web/WebRemoteFrameClient.h:25: virtual void navigate(WebRemoteFrame*
frame, const WebURLRequest& request,
Do we need to pass a frame parameter here?

[Nate Chapin, 2014-09-25 20:19:19]

https://codereview.chromium.org/573353002/diff/40001/Source/core/frame/Frame.h
File Source/core/frame/Frame.h (right):

https://codereview.chromium.org/573353002/diff/40001/Source/core/frame/Frame....
Source/core/frame/Frame.h:34: #include "platform/weborigin/Referrer.h"
On 2014/09/25 00:21:19, dcheng wrote:
> Do we prefer to forward declare in this case to minimize the amount of
#includes
> in headers?

Yeah, don't remember why I did it this way. Done.

https://codereview.chromium.org/573353002/diff/40001/public/web/WebRemoteFram...
File public/web/WebRemoteFrameClient.h (right):

https://codereview.chromium.org/573353002/diff/40001/public/web/WebRemoteFram...
public/web/WebRemoteFrameClient.h:25: virtual void navigate(WebRemoteFrame*
frame, const WebURLRequest& request,
On 2014/09/25 00:21:19, dcheng wrote:
> Do we need to pass a frame parameter here?

No, that's just The Way We've Always Done It.

Will remove.

[dcheng, 2014-09-25 23:49:35]

lgtm

[Nate Chapin, 2014-09-26 16:43:44]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2014-09-26 16:44:12]

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

[commit-bot: I haz the power, 2014-09-26 16:52:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-26 16:52:30]

Try jobs failed on following builders:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)

[abarth-chromium, 2014-09-26 19:57:33]

public LGTM

[Nate Chapin, 2014-09-26 19:57:50]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2014-09-26 19:58:02]

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

[commit-bot: I haz the power, 2014-09-26 22:03:33]

Committed patchset #4 (id:60001) as 182795