Teach navigation throttles how to cancel requests in WillProcessResponse.

content/browser/loader/navigation_resource_throttle.cc

Index: content/browser/loader/navigation_resource_throttle.cc
diff --git a/content/browser/loader/navigation_resource_throttle.cc b/content/browser/loader/navigation_resource_throttle.cc
index 44fd0c131ff413fd0d90d0d4c07adae7dedc338b..657f6983166da5aaddc7aafac03d114dbe54124c 100644
--- a/content/browser/loader/navigation_resource_throttle.cc
+++ b/content/browser/loader/navigation_resource_throttle.cc
@@ -5,8 +5,10 @@
 #include "content/browser/loader/navigation_resource_throttle.h"
 
 #include "base/callback.h"
+#include "base/logging.h"
 #include "content/browser/frame_host/navigation_handle_impl.h"
 #include "content/browser/frame_host/render_frame_host_impl.h"
+#include "content/public/browser/browser_thread.h"
 #include "content/public/browser/resource_context.h"
 #include "content/public/browser/resource_controller.h"
 #include "content/public/browser/resource_request_info.h"
@@ -26,7 +28,27 @@ typedef base::Callback<void(NavigationThrottle::ThrottleCheckResult)>
 void SendCheckResultToIOThread(UIChecksPerformedCallback callback,
                                NavigationThrottle::ThrottleCheckResult result) {
   DCHECK_CURRENTLY_ON(BrowserThread::UI);
-  CHECK(result != NavigationThrottle::DEFER);
+  CHECK_NE(result, NavigationThrottle::DEFER);

[clamy, 2016/01/26 14:08:55]

DCHECK? I think we're trying to avoid CHECKs in the code.

[Mike West, 2016/01/27 07:44:33]

Done.

+  BrowserThread::PostTask(BrowserThread::IO, FROM_HERE,
+                          base::Bind(callback, result));
+}
+
+void MaybeCommitNavigationAndSendCheckResultToIOThread(
+    UIChecksPerformedCallback callback,
+    int render_process_id,
+    int render_frame_host_id,
+    scoped_refptr<net::HttpResponseHeaders> headers,
+    NavigationThrottle::ThrottleCheckResult result) {
+  DCHECK_CURRENTLY_ON(BrowserThread::UI);
+  CHECK_NE(result, NavigationThrottle::DEFER);

[mmenke, 2016/01/26 16:40:08]

DCHECK here, as well, I assume.

[Mike West, 2016/01/27 07:44:33]

Done.

+  if (result == NavigationThrottle::PROCEED) {
+    RenderFrameHostImpl* render_frame_host =
+        RenderFrameHostImpl::FromID(render_process_id, render_frame_host_id);
+    if (render_frame_host && render_frame_host->navigation_handle()) {
+      render_frame_host->navigation_handle()->ReadyToCommitNavigation(
+          render_frame_host, headers);

[mmenke, 2016/01/26 16:40:08]

This seems weird.  We call into the NavigationHandle, and tell it to call us
back.  If it calls us back, and it told us to proceed, we then call *back* into
the NavigationHandle, telling it that it told us to proceed?

[Mike West, 2016/01/27 07:44:33]

As I noted in my response to clamy@, it made sense to me to think of the
NavigationResourceThrottle as being in control of the navigation, and the
NavigationHandle as something of a state machine. But both of you have flagged
this as being weird, so I'm happy to agree. :)

+    }
+  }
   BrowserThread::PostTask(BrowserThread::IO, FROM_HERE,
                           base::Bind(callback, result));
 }
@@ -93,21 +115,29 @@ void CheckWillRedirectRequestOnUIThread(
 }
 
 void WillProcessResponseOnUIThread(
+    UIChecksPerformedCallback callback,
     int render_process_id,
     int render_frame_host_id,
     scoped_refptr<net::HttpResponseHeaders> headers) {
   DCHECK_CURRENTLY_ON(BrowserThread::UI);
   RenderFrameHostImpl* render_frame_host =
       RenderFrameHostImpl::FromID(render_process_id, render_frame_host_id);
-  if (!render_frame_host)
+  if (!render_frame_host) {
+    SendCheckResultToIOThread(callback, NavigationThrottle::PROCEED);
     return;
+  }
 
   NavigationHandleImpl* navigation_handle =
       render_frame_host->navigation_handle();

[mmenke, 2016/01/26 16:40:08]

How sure are we that this is our navigation handle, and not that for a new
navigation?  I don't see a cancellation path.

-  if (!navigation_handle)
+  if (!navigation_handle) {
+    SendCheckResultToIOThread(callback, NavigationThrottle::PROCEED);
     return;
+  }
 
-  navigation_handle->ReadyToCommitNavigation(render_frame_host, headers);
+  navigation_handle->WillProcessResponse(
+      headers,
+      base::Bind(&MaybeCommitNavigationAndSendCheckResultToIOThread, callback,
+                 render_process_id, render_frame_host_id, headers));

[mmenke, 2016/01/26 16:40:08]

Hrm...Does seem kinda weird to me that the NavigationHandle doesn't know its own
render frame IDs

[clamy, 2016/01/26 16:48:05]

This is because the NavigationHandle was built as an interface that works both
with the current navigation architecture and with PlzNavigate. In PlzNavigate
you only get a RFH after processing the response, so the NavigationHandle does
not know it before that point.

 }
 
 }  // namespace
@@ -204,10 +234,15 @@ void NavigationResourceThrottle::WillProcessResponse(bool* defer) {
         request_->response_headers()->raw_headers());
   }
 
+  UIChecksPerformedCallback callback =
+      base::Bind(&NavigationResourceThrottle::OnUIChecksPerformed,
+                 weak_ptr_factory_.GetWeakPtr());
+
   BrowserThread::PostTask(
       BrowserThread::UI, FROM_HERE,
-      base::Bind(&WillProcessResponseOnUIThread, render_process_id,
+      base::Bind(&WillProcessResponseOnUIThread, callback, render_process_id,
                  render_frame_id, response_headers));
+  *defer = true;
 }
 
 const char* NavigationResourceThrottle::GetNameForLogging() const {