Create RenderFrame/RenderFrameHost for the main frame of a page.

content/public/renderer/render_frame.h

+// 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_PUBLIC_RENDERER_RENDER_FRAME_H_
+#define CONTENT_PUBLIC_RENDERER_RENDER_FRAME_H_
+
+#include "content/common/content_export.h"
+#include "ipc/ipc_listener.h"
+#include "ipc/ipc_sender.h"
+
+namespace content {
+
+class CONTENT_EXPORT RenderFrame : public IPC::Listener,

[jam, 2013/05/31 17:40:04]

nits:
-this class needs to be documented
-does this really need to be exported? doesn't look like it

also, are you sure this will be used by emebedders? i.e. do we need to expose
this through the content api, or can it be an implementation detail? right now
it's empty so obviously it's not used, but I don't know what your plans are for
it going forward, hence the question

[nasko, 2013/05/31 17:58:30]

This will have to be exported, as we will migrate all functionality of
WebFrameClient from RenderView to RenderFrame. Mentally I'm thinking of
RenderFrame as carving out functionality of RenderView into a separate class. If
any out-of-content code is using frame related functionality of RenderView, then
they will need to use RenderFrame. A simple example of this will be navigation.
<webview> is already planning to move to observers for navigations, so they will
need to know which frame it is for and with the goal of moving <webview> out of
content, this will require us to expose RenderFrame out.

I've added a basic comment and plan on expanding it as we add more
functionality.

+                                   public IPC::Sender {
+ protected:
+  virtual ~RenderFrame() {}
+
+ private:
+  // This interface should only be implemented inside content.
+  friend class RenderFrameImpl;
+  RenderFrame() {}
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_RENDERER_RENDER_FRAME_H_