Move ownership of CrossProcessFrameConnector to RenderFrameProxyHost.

content/browser/frame_host/render_frame_host_impl.cc

Index: content/browser/frame_host/render_frame_host_impl.cc
diff --git a/content/browser/frame_host/render_frame_host_impl.cc b/content/browser/frame_host/render_frame_host_impl.cc
index a9434607bc0b925aedb5815a8b6fb030371613fc..397fd915ea49d5281d95a1dfc2e6115228019a2d 100644
--- a/content/browser/frame_host/render_frame_host_impl.cc
+++ b/content/browser/frame_host/render_frame_host_impl.cc
@@ -279,8 +279,10 @@ bool RenderFrameHostImpl::OnMessageReceived(const IPC::Message &msg) {
   if (delegate_->OnMessageReceived(this, msg))
     return true;
 
-  if (cross_process_frame_connector_ &&
-      cross_process_frame_connector_->OnMessageReceived(msg))
+  RenderFrameProxyHost* proxy =
+      frame_tree_node_->render_manager()->GetProxyToParent();
+  if (proxy && proxy->cross_process_frame_connector() &&
+      proxy->cross_process_frame_connector()->OnMessageReceived(msg))

[kenrb, 2014/06/19 14:49:04]

This doesn't look right to me. The original line here existed for intercepting
messages coming from the parent frame renderer, going to the child frame
renderer (e.g. input events, resize). This appears to be going the wrong way.

Really, this should be in RenderFrameProxyHost, and use its CPFC pointer, but I
don't know if RFPH actually receives messages yet.

[nasko, 2014/06/19 15:46:41]

I don't think this is correct and is the reason I've given feedback before on
the "child" naming on the method and IPC. The IPC comes from the RenderFrame
that is about to navigate cross-process, not from its parent frame.
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...
I contemplated this before and had it coded, but decided to be more explicit
that only messages related to CPFC need to be forwarded, not any other IPC.

[kenrb, 2014/06/19 16:16:32]

I feel like I am missing something here. Does input event forwarding work with
this patch in place?

[nasko, 2014/06/19 16:24:35]

Yes : ). Input events are delivered to the child frame in the parent process,
then sent through IPC up to the browser, right? So in the picture of CPFC
header, they are delivered to A2, which is the proxy/swapped out frame. This is
A2 and it forwards those events to CPFC. Similar code will exist in the proxy
object, once the IPCs flow to it instead of the swapped out RFHs.

[kenrb, 2014/06/19 17:07:08]

Okay, I find GetProxyToParent() is confusing because this RenderFrameHost is
already for a RenderFrame in the parent process. I guess this gets cleared up
when RenderFrameHostProxy replaces the A2 RenderFrameHost, rather than
coexisting with it?

Will GetProxyToParent() be removed at that point? I feel like we shouldn't need
that function.

[nasko, 2014/06/19 17:12:38]

The goal is to get the proxy, which is in the same SiteInstance as the parent.
Do you have any suggestion on how to rename it to be more clear?
I still think it will be needed in RenderFrameHostManager, since we want to
update the RWHV on the proper proxy, right? Though at that point it will be
internal to RFHM and should not be needed outside of it I think.

[nasko, 2014/06/19 17:52:05]

Actually, even at the end, we still need this code. The reason is that when
executing OnSwapOut in RenderFrame, we mark the WebFrame as remote, which
results in calling back into RenderFrame to send out the sizing information.
That will still need to be forwarded to the CPFC, so this code will have to
stay.
If we want to eliminate this code here, sizing data will have to be sent
directly to the proxy, potentially handled all within RenderFrame (though I
don't have enough data at this point to see if it is possible).

[kenrb, 2014/06/19 18:03:35]

My intent was that everything would go through the proxy, rather than having two
code paths for the in-process child frame to out-of-process child frame
communication channel. I think that would be preferable if possible.

     return true;
 
   bool handled = true;