Give the main frame a RenderWidget.

content/public/browser/web_contents.h

Index: content/public/browser/web_contents.h
diff --git a/content/public/browser/web_contents.h b/content/public/browser/web_contents.h
index 803b816ff07eecc24f23bd69bcba4122b071076a..711b97dcd011de4c7099e75c6e7cdfb490f981c4 100644
--- a/content/public/browser/web_contents.h
+++ b/content/public/browser/web_contents.h
@@ -112,11 +112,13 @@ class WebContents : public PageNavigator,
     // (e.g., for blocked popups).
     bool created_with_opener;
 
-    // The routing ids of the RenderView and of the main RenderFrame. Either
-    // both must be provided, or both must be MSG_ROUTING_NONE to have the
-    // WebContents make the assignment.
-    int routing_id;
-    int main_frame_routing_id;
+    // The routing ids of the RenderView, main RenderFrame, and the widget for
+    // the main RenderFrame. Either all routing IDs must be provided or all must
+    // be MSG_ROUTING_NONE to have WebContents make the assignment.
+    // TODO(dcheng): what the heck does 'make the assignment' even mean?!

[Avi (use Gerrit), 2015/08/28 01:34:49]

Sigh. Welcome to hell. There are two code paths here.

=== The top-down path ===

WebContents* wc = WebContents::Create();

In this case, we're creating the WebContents in the browser, but there is
nothing on the renderer side yet. The code flow eventually hits
RenderFrameHostManager::CreateRenderFrameHost, which says "hey, we need a frame
routing id and don't have one, so let's make one up". It then calls through to
the RenderWidgetHostImpl constructor which says "hey, we need a routing id and
don't have one, so let's make one up".

At that point, the routing IDs are set up in the browser process, and when the
ViewMsg_New IPC is sent to the renderer, the renderer knows what routing IDs to
use.

In this case, for the call to WebContents::Create(), MSG_ROUTING_NONE is used
because there is no established routing. In the course of creating the
WebContents, eventually routing IDs will be assigned, but here you're letting
the WebContents "make the assignment" of the routing IDs.

=== The bottom-up path ===

window.open(url, title, params)

In this case, the renderer needs to create a new WebContents.
RenderViewImpl::createView sends ViewHostMsg_CreateWindow, which eventually ends
up in RenderWidgetHelper::CreateNewWindow, which IS ON THE WRONG THREAD! So it
makes up routing ids and returns them to the renderer via the return IPC.
Meanwhile, it jumps to the UI thread in RenderWidgetHelper::OnCreateWindowOnUI,
which calls RenderViewHostImpl::CreateNewWindow which calls
WebContentsImpl::CreateNewWindow.

At this point, the browser has already told the renderer what routing ids to
use, so in setting up the browser side, WebContents has to use those routing
ids. Thus the parameters.

===

The main problem here is the threading. If we weren't on the wrong thread, sure,
when we got the ViewHostMsg_CreateWindow IPC we could just make up a new
WebContents, get the routing IDs, and return them. But we can't.

There surely must be something that can be done to improve this, though.

+    int32 routing_id;
+    int32 main_frame_routing_id;
+    int32 main_frame_widget_routing_id;
 
     // The name of the top-level frame of the new window. It is non-empty
     // when creating a named window (e.g. <a target="foo"> or