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

content/renderer/render_frame_impl.cc

+// 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.
+
+#include "content/renderer/render_frame_impl.h"
+
+#include "content/renderer/render_thread_impl.h"
+#include "content/renderer/render_view_impl.h"
+
+namespace content {
+
+RenderFrameImpl::RenderFrameImpl(RenderViewImpl* render_view, int routing_id)
+    : render_view_(render_view),
+      routing_id_(routing_id) {
+}
+
+RenderFrameImpl::~RenderFrameImpl() {
+}
+
+bool RenderFrameImpl::Send(IPC::Message* message) {
+  // If given a messsage without a routing ID, then assign our routing ID.

[Charlie Reis, 2013/05/30 18:26:59]

Why aren't we going through the RenderView / RenderWidget here, as in
RenderFrameHost?  This would send messages even when the RenderView is swapped
out, since it skips the check in RenderWidget::Send.

[nasko, 2013/05/30 19:03:48]

The reason I've done it is that a RenderFrame could be active even if the
RenderView is swapped out, but at this stage this is impossible. I've added a
comment to ensure stop using the RenderView once we have enough support for it.

+  if (message->routing_id() == MSG_ROUTING_NONE)
+    message->set_routing_id(routing_id_);
+
+  return RenderThread::Get()->Send(message);
+}
+
+bool RenderFrameImpl::OnMessageReceived(const IPC::Message &msg) {
+  // Pass the message up to the RenderView, until we have enough
+  // infrastructure to start processing messages in this object.
+  return render_view_->OnMessageReceived(msg);
+}
+
+}  // namespace content