Introduce RenderFrameProxyHost object and use it in RFHM.

content/browser/frame_host/render_frame_proxy_host.h

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_BROWSER_FRAME_HOST_RENDER_FRAME_PROXY_HOST_H_
+#define CONTENT_BROWSER_FRAME_HOST_RENDER_FRAME_PROXY_HOST_H_
+
+#include "base/memory/scoped_ptr.h"
+#include "content/browser/frame_host/render_frame_host_impl.h"
+
+class RenderProcessHost;
+class RenderFrameHostImpl;
+class RenderViewHostImpl;
+
+namespace content {
+
+// When a page is rendered across multiple processes, each renderer has a

[Charlie Reis, 2014/04/09 21:48:30]

nit: a page's frames are rendered by multiple

[nasko, 2014/04/10 20:37:36]

Done.

+// full copy of the frame tree. It has real frame objects for the frames it is

[Charlie Reis, 2014/04/09 21:48:30]

real frame objects -> full RenderFrames

[nasko, 2014/04/10 20:37:36]

Done.

+// responsible for rendering and placeholder objects for frames rendered by

[Charlie Reis, 2014/04/09 21:48:30]

placeholder objects (i.e., RenderFrameProxies)

[nasko, 2014/04/10 20:37:36]

Done.

+// other processes - RenderFrameProxy.

[Charlie Reis, 2014/04/09 21:48:30]

nit: Blank line after this paragraph.

[nasko, 2014/04/10 20:37:36]

Done.

+// This class is the browser-site object for the placeholder. Each node in the

[Charlie Reis, 2014/04/09 21:48:30]

browser-side host object

[nasko, 2014/04/10 20:37:36]

Too much "site" isolation ;)

+// frame tree has a RenderFrameHost for the SiteInstance of the frame and a set

[Charlie Reis, 2014/04/09 21:48:30]

for the active SiteInstance and a set

[nasko, 2014/04/10 20:37:36]

Done.

+// of RenderFrameProxyHost objects - one for all other SiteInstances associated

[Charlie Reis, 2014/04/09 21:48:30]

associated with the frame tree -> with references to this frame

[nasko, 2014/04/10 20:37:36]

Done.

+// with the frame tree. The proxies allow us to keep existing window references
+// valid over cross-process navigations and route cross-site asynchronous
+// JavaScript calls, such as postMessage.
+//
+// For now, RenderFrameProxyHost is created when a RenderFrameHost is swapped
+// out and acts just as a wrapper. If a RenderFrameHost can be deleted, no
+// proxy object is created. It is destroyed when the RenderFrameHost is swapped
+// back in or is no longer referenced and is therefore deleted.
+//
+// Long term, RenderFrameProxyHost will be created whenever a cross-site
+// navigation occurs and a reference to the frame navigating needs to be kept
+// alive. RenderFrameProxyHost and RenderFrameHost for the same SiteInstance can

[Charlie Reis, 2014/04/09 21:48:30]

A RenderFrameHost and a RenderFrameProxyHost for

[nasko, 2014/04/10 20:37:36]

Done.

+// exist at the same time, but only one will be "active" at a time.

[Charlie Reis, 2014/04/09 21:48:30]

I don't understand what "active" means here.  I didn't think
RenderFrameProxyHost was ever considered active.

[nasko, 2014/04/10 20:37:36]

The object to use when sending IPC messages. I don't quite like the word active
(from previous experiences ;) ), but I'm not sure what is a better one.

[Charlie Reis, 2014/04/11 17:42:53]

If I understand the reason this can happen correctly, what about this?

"A RenderFrameProxyHost and a RenderFrameHost for the same SiteInstance can
exist at the same time, but only while the RenderFrameHost is waiting to be
deleted in the background."

+// There are two cases where the two objects will coexist:
+// * When navigating cross-process and there is already a RenderFrameProxyHost
+// for the new SiteInstance. A pending RenderFrameHost is created, but it is
+// not used until it commits. At that point, RenderFrameHostManager transitions
+// the pending RenderFrameHost to the active one and deletes the proxy.
+// * When navigating cross-process and the existing document has an unload
+// event handler. When the new navigation commits, RenderFrameHostManager
+// creates a RenderFrameProxyHost for the old SiteInstance and uses it going
+// forward. It also instructs the RenderFrameHost to run the unload event
+// handler and is kept alive for the duration. Once the event handling is
+// complete, the RenderFrameHost is deleted.
+//

[Charlie Reis, 2014/04/09 21:48:30]

nit: Remove empty comment line.

[nasko, 2014/04/10 20:37:36]

Done.

+class RenderFrameProxyHost {
+ public:
+   explicit RenderFrameProxyHost(
+       scoped_ptr<RenderFrameHostImpl> render_frame_host);
+  ~RenderFrameProxyHost();
+
+  RenderProcessHost* GetProcess() {
+    return render_frame_host_->GetProcess();
+  }
+  RenderFrameHostImpl* render_frame_host() {

[Charlie Reis, 2014/04/09 21:48:30]

Can you move render_frame_host(), render_view_host(), and PassFrameHost() down a
bit into a block with a TODO to remove them?  We'll be keeping GetProcess().

[nasko, 2014/04/10 20:37:36]

Done.

+    return render_frame_host_.get();
+  }
+  RenderViewHostImpl* render_view_host() {
+    return render_frame_host_->render_view_host();
+  }
+  scoped_ptr<RenderFrameHostImpl> PassFrameHost() {
+    return render_frame_host_.Pass();
+  }
+
+ private:
+

[Charlie Reis, 2014/04/09 21:48:30]

nit: No blank line here.

[nasko, 2014/04/10 20:37:36]

Done.

+  // TODO(nasko): For now, hide the RenderFrameHost inside the proxy, but remove
+  // it once we have all the code support for proper proxy objects.
+  scoped_ptr<RenderFrameHostImpl> render_frame_host_;
+
+  DISALLOW_COPY_AND_ASSIGN(RenderFrameProxyHost);
+};
+
+}  // namespace
+
+#endif  // CONTENT_BROWSER_FRAME_HOST_RENDER_FRAME_PROXY_HOST_H_