Drop CreateChildFrame messages when swapping out.

content/browser/frame_host/render_frame_host_impl.cc

Index: content/browser/frame_host/render_frame_host_impl.cc
diff --git a/content/browser/frame_host/render_frame_host_impl.cc b/content/browser/frame_host/render_frame_host_impl.cc
index 436f4fbad1ac99df7ec45e782d7218d9f4df1774..9543334e9da3d5fc8b8105e8bff0192bf3e34a5d 100644
--- a/content/browser/frame_host/render_frame_host_impl.cc
+++ b/content/browser/frame_host/render_frame_host_impl.cc
@@ -611,6 +611,13 @@ void RenderFrameHostImpl::OnAddMessageToConsole(
 
 void RenderFrameHostImpl::OnCreateChildFrame(int new_routing_id,
                                              const std::string& frame_name) {
+  // It is possible that while a new RenderFrameHost was committed, the
+  // RenderFrame corresponding to this host sent an IPC message to create a
+  // frame and it is delivered after this host is swapped out.
+  // Ignore such messages, as we know this RenderFrameHost is going away.
+  if (rfh_state_ != RenderFrameHostImpl::STATE_DEFAULT)
+    return;
+
   RenderFrameHostImpl* new_frame = frame_tree_->AddFrame(

[Charlie Reis, 2014/10/15 23:54:18]

FrameTree::AddFrame is still a problematic API, in my opinion.  It assumes the
new_routing_id is from the current process, and that turns out to be easy to
violate.  We should make it take in both a process ID and the routing ID, so
that we can verify we're using the right process internally.

It's fine to do that in a follow-up CL if you'd prefer, since I think this is
the only call-site and there shouldn't be a way for the process to be different
while this RFH not in the default state.  Might be nice to get it done all at
once, though.

[nasko, 2014/10/16 17:08:36]

No need for follow up CL. Let's do it right from the beginning.

       frame_tree_node_, new_routing_id, frame_name);