Create a new RenderFrameHost per child frame when --site-per-process is enabled.

content/browser/renderer_host/render_view_host_impl.h

Index: content/browser/renderer_host/render_view_host_impl.h
diff --git a/content/browser/renderer_host/render_view_host_impl.h b/content/browser/renderer_host/render_view_host_impl.h
index 8c05c8f23012a942e1a14b5ce53a95a40440ba38..67ad3ee1f5e1bf4de90f1c761d38f3611b39ad25 100644
--- a/content/browser/renderer_host/render_view_host_impl.h
+++ b/content/browser/renderer_host/render_view_host_impl.h
@@ -462,6 +462,10 @@ class CONTENT_EXPORT RenderViewHostImpl
   // the caller places are in different platforms, in which case it's better
   // to keep them consistent).
 
+  // Called to associate this RenderViewHost with the FrameTree given at
+  // construction. See comment about |main_render_frame_host_| for details.
+  void SwapIntoFrameTree(RenderViewHostImpl* old_render_view_host);

[Charlie Reis, 2013/09/11 22:25:04]

I'm having trouble with this contract.  I guess it's because you're putting the
RFH back on the old RVH, but this seems awkward to keep switching ownership.

+
  protected:
   friend class RenderViewHostObserver;
 
@@ -598,10 +602,15 @@ class CONTENT_EXPORT RenderViewHostImpl
 
   bool CanAccessFilesOfPageState(const PageState& state) const;
 
-  // This is an RenderFrameHost object associated with the top-level frame in
-  // the page rendered by this RenderViewHost.
-  // TODO(nasko): Remove this pointer once we have enough infrastructure to
-  // move this to the top-level FrameTreeNode.
+  // All RenderViewHosts must have a RenderFrameHost for its main frame
+  // thus the RenderFrameHost is created in lock step on construction.
+  // In a WebContents, the FrameTree owns the RenderFrameHost and ownership
+  // is transfered once this RenderViewHost commits.

[Charlie Reis, 2013/09/11 22:25:04]

Is this a temporary thing, such that we should have a TODO saying that it will
go away once we have a RenderFrameHostManager for keeping track of pending RFHs?

[Charlie Reis, 2013/09/24 18:25:58]

Done.

+  //
+  // For standalone RenderViewHosts such as those used by interstitial pages,

[nasko, 2013/09/11 22:26:24]

I wonder if this is going to be true long term. It looks like RenderFrameHost
will take care of painting, so we will have to have one for every
RenderViewHost. Just putting thinking into writing though.

+  // this is the sole reference because there is no FrameTree. Also, when the

[Charlie Reis, 2013/09/11 22:25:04]

I don't think this makes sense.  Interstitial pages can have iframes, right? 
We'll need to somehow support that.

+  // RenderViewHost swaps out, the reference is given back so it can be held in
+  // the swapped out state.
   scoped_ptr<RenderFrameHostImpl> main_render_frame_host_;
 
   // Our delegate, which wants to know about changes in the RenderView.