OOPIF: Handle cross-site frames being blocked by X-Frame-Options or CSP.

content/browser/frame_host/render_frame_host_manager.cc

Index: content/browser/frame_host/render_frame_host_manager.cc
diff --git a/content/browser/frame_host/render_frame_host_manager.cc b/content/browser/frame_host/render_frame_host_manager.cc
index df798cfc97d3f34cde8b27183a7adcb62aaf2eb2..4766646ffa343a983d2df5699b2f0c3a9b8572b9 100644
--- a/content/browser/frame_host/render_frame_host_manager.cc
+++ b/content/browser/frame_host/render_frame_host_manager.cc
@@ -458,15 +458,25 @@ void RenderFrameHostManager::OnCrossSiteResponse(
   pending_render_frame_host->set_is_loading(false);
 
   // Sanity check that the params are for the correct frame and process.
-  // These should match the RenderFrameHost that made the request.
-  // If it started as a cross-process navigation via OpenURL, this is the
-  // pending one.  If it wasn't cross-process until the transfer, this is
-  // the current one.
-  int render_frame_id = pending_render_frame_host_
-                            ? pending_render_frame_host_->GetRoutingID()
-                            : render_frame_host_->GetRoutingID();
-  DCHECK_EQ(render_frame_id, pending_render_frame_host->GetRoutingID());
-  int process_id = pending_render_frame_host_ ?
+  // These should match the RenderFrameHost that made the request. If it
+  // started as a cross-process navigation via OpenURL, this is the pending
+  // one.  If it wasn't cross-process until the transfer, this is the current
+  // one.
+  //
+  // Note that having a pending RenderFrameHost does not imply that it was the
+  // one that made the request.  Suppose that during a pending cross-site
+  // navigation, the frame performs a different same-site navigation which
+  // redirects cross-site.  In this case, there will be a pending
+  // RenderFrameHost, but this request is made by the current RenderFrameHost.
+  // Later, this will create a new pending RenderFrameHost and clean up the old
+  // one.
+  int request_routing_id = pending_render_frame_host->GetRoutingID();
+  int pending_routing_id = pending_render_frame_host_ ?
+      pending_render_frame_host_->GetRoutingID() :
+      MSG_ROUTING_NONE;
+  DCHECK(request_routing_id == pending_routing_id ||

[alexmos, 2016/02/25 21:59:12]

Relaxing this DCHECK was necessary to enable navigating the blocked subframe to
a different site (c.com in my test), and we discussed that it might happen more
generically.

[Charlie Reis, 2016/02/26 21:26:41]

Yep.  I wouldn't be opposed to landing this change before the rest of the CL if
we think it can happen generally.  It seems relatively unrelated to the rest of
the blocking logic.

[alexmos, 2016/02/26 22:37:56]

Agreed.  I split this off into https://codereview.chromium.org/1736393002/ and
just sent to you.

+         request_routing_id == render_frame_host_->GetRoutingID());
+  int process_id = request_routing_id == pending_routing_id ?
       pending_render_frame_host_->GetProcess()->GetID() :
       render_frame_host_->GetProcess()->GetID();
   DCHECK_EQ(process_id, global_request_id.child_id);