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 f883a45098cb08d4634e0c40f904f8aa70943d1e..4b2e986468f4f5b828e03eab41fb2ab9ce2cfff8 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()->ProxyToParent();

[kenrb, 2014/06/06 15:45:54]

I think this is the problem. This message intercept here is intended to
intercept messages coming *from* the parent frame renderer and going *to* the
child frame renderer. This is currently exercised when the current
RenderFrameHostImpl is swapped out and has a CPFC -- indicating that it is
responsible for passing input events and iframe size information to its child.

In the current form, do we still have a parent-renderer RenderFrameHost for the
swapped out child, or has that been replaced with RenderFrameProxyHost yet? If
it has been replaced (I don't think it has, but I haven't been following
closely), this intercept just goes there -- the RFPH should be receiving the
message from the RenderFrameProxy. Otherwise, I'm not sure what the current
configuration of RenderFrameProxy and RenderFrameProxyHost looks like for a
swapepd out child frame.

+  if (proxy && proxy->cross_process_frame_connector() &&
+      proxy->cross_process_frame_connector()->OnMessageReceived(msg))
     return true;
 
   bool handled = true;