Adding RenderWidgetHostViewChildFrame for OOPIF view.

content/browser/frame_host/cross_process_frame_connector.h

Index: content/browser/frame_host/cross_process_frame_connector.h
diff --git a/content/browser/frame_host/cross_process_frame_connector.h b/content/browser/frame_host/cross_process_frame_connector.h
new file mode 100644
index 0000000000000000000000000000000000000000..5c8764490f2c966d47b4bbe5dc7c98e0da33ada5
--- /dev/null
+++ b/content/browser/frame_host/cross_process_frame_connector.h
@@ -0,0 +1,81 @@
+// Copyright (c) 2013 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_CROSS_PROCESS_FRAME_CONNECTOR_H_
+#define CONTENT_BROWSER_FRAME_HOST_CROSS_PROCESS_FRAME_CONNECTOR_H_
+
+#include "cc/output/compositor_frame.h"
+#include "ui/gfx/rect.h"
+
+namespace IPC {
+class Message;
+}
+
+struct GpuHostMsg_AcceleratedSurfaceBuffersSwapped_Params;
+
+namespace content {
+class RenderFrameHostImpl;
+class RenderWidgetHostImpl;
+class RenderWidgetHostViewChildFrame;
+
+// -----------------------------------------------------------------------------
+// CrossProcessFrameConnector mediates between a parent frame and an embedded

[Charlie Reis, 2013/12/12 02:42:05]

Thanks-- I like the name much more than CrossProcessChildFrame.

I'm not sure what "mediates" means here.  Can you elaborate in the comment?

[kenrb, 2013/12/13 18:41:17]

Done.

+// child frame that is rendered in a separate process. It contains browser
+// process state for the child frame and has logic for message passing between

[Charlie Reis, 2013/12/12 02:42:05]

nit: passing messages

+// them. It is owned by the child frame's RenderFrameHostManager.
+// -----------------------------------------------------------------------------
+class CrossProcessFrameConnector {
+ public:
+  virtual ~CrossProcessFrameConnector();
+
+  static CrossProcessFrameConnector* CreateCrossProcessFrameConnector(
+      RenderFrameHostImpl* frame_proxy_to_parent_renderer);

[Charlie Reis, 2013/12/12 02:42:05]

Please document what this parameter is supposed to be.  I'm not sure what I
would pass in if I called it.

[kenrb, 2013/12/13 18:41:17]

Would this be redundant with the comment on the member variable of the same
name? Or would the description be better here than down there?

[Charlie Reis, 2013/12/16 19:31:08]

That comment says it's initially NULL, which doesn't make sense if we're
supposed to pass it into a creation method.

+
+  void Destroy();
+
+  bool OnMessageReceived(const IPC::Message &msg);
+
+  void SetView(RenderWidgetHostViewChildFrame* view);
+
+  // 'Platform' functionality exposed to RenderWidgetHostViewChildFrame.
+  // These methods can forward messages to the child frame proxy in the parent
+  // frame renderer or attempt to handle them within the browser process.
+  void ChildFrameBuffersSwapped(
+      const GpuHostMsg_AcceleratedSurfaceBuffersSwapped_Params& params,
+      int gpu_host_id);
+
+  void ChildFrameCompositorFrameSwapped(
+      uint32 output_surface_id,
+      scoped_ptr<cc::CompositorFrame> frame);
+
+  gfx::Rect ChildFrameRect();
+
+ private:
+  CrossProcessFrameConnector(
+      RenderFrameHostImpl* frame_proxy_to_parent_renderer);
+
+  // Handlers for messages received from the parent frame.
+  void OnBuffersSwappedACK(std::string mailbox_name,
+                           int route_id,
+                           int gpu_host_id,
+                           uint32 sync_point);
+
+  // frame_proxy_to_parent_renderer_ the RenderFrameHostProxy that routes

[Charlie Reis, 2013/12/12 02:42:05]

nit: is the

Actually, just start with "The" and skip the member name, here and below.

[kenrb, 2013/12/13 18:41:17]

Done.

+  // messages to the parent frame's renderer process. Initially NULL.
+  // TODO(kenrb): The type becomes RenderFrameProxyHost when that class comes
+  // to exist.
+  RenderFrameHostImpl* frame_proxy_to_parent_renderer_;
+
+  // child_frame_widget_ is the RenderWidgetHost for the child_frame. There is
+  // at most one RenderWidgetHost per frame because RenderFrameProxyHosts do
+  // not do not require widgets.
+  RenderWidgetHostImpl* child_frame_widget_;

[Charlie Reis, 2013/12/12 02:42:05]

Why isn't this on RenderFrameHostImpl instead?  I thought we were eventually
going to move to RFHs having a RWH.

[kenrb, 2013/12/13 18:41:17]

RenderWidgetHostImpl will be owned by RenderFrameHostImpl (eventually), and
RenderFrameHostImpl is responsible for setting and clearing the pointer in
CrossProcessFrameConnector. It needs to be cached rather than accessed directly
because this class shouldn't need a pointer to RenderFrameHostImpl (not counting
the stub RFH in the parent process, which should be a RenderFrameProxyHostImpl).

[Charlie Reis, 2013/12/16 19:31:08]

What do you mean by cached?  Will it ever be stale?  Or do you mean it's just
stored here rather than there?

It seems like this is information that belongs on RenderFrameProxyHost, and
might more naturally belong on RenderFrameHost in the meantime.  Then we might
not need this class at all.  (Sorry, I'm sure I'm missing something, but I want
to understand why this class is needed before we proceed with it.)

+
+  gfx::Rect child_frame_rect_;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_FRAME_HOST_CROSS_PROCESS_FRAME_CONNECTOR_H_
+