Add a way to cancel deferred navigations in NavigationHandle

content/public/browser/navigation_throttle.h

Index: content/public/browser/navigation_throttle.h
diff --git a/content/public/browser/navigation_throttle.h b/content/public/browser/navigation_throttle.h
index c5202ae71d89d47990394423a87c943af488d66c..dd07463822cf47f87055bc7d45480e7bb9760578 100644
--- a/content/public/browser/navigation_throttle.h
+++ b/content/public/browser/navigation_throttle.h
@@ -17,8 +17,20 @@ class CONTENT_EXPORT NavigationThrottle {
   // This is returned to the NavigationHandle to allow the navigation to
   // proceed, or to cancel it.
   enum ThrottleCheckResult {
+    // The navigation proceeds uninterrupted.
     PROCEED,
+
+    // Defers the navigation until the NavigationThrottle calls
+    // NavigationHandle::Resume or NavigationHandle::CancelDeferredRequest.
+    // If the NavigationHandle is destroyed while the navigation is deferred,
+    // the navigation will be canceled in the network stack.
     DEFER,
+
+    // Cancels the navigation.
+    CANCEL,
+
+    // Cancels the navigation and makes the requester of the navigation acts
+    // like the request was never made.
     CANCEL_AND_IGNORE,
   };
 
@@ -26,9 +38,21 @@ class CONTENT_EXPORT NavigationThrottle {
   virtual ~NavigationThrottle();
 
   // Called when a network request is about to be made for this navigation.
+  //
+  // The implementer is responsible for ensuring that the WebContents remain
+  // alive during teh duration of this method. Failing to do so will result in

[mnaganov (inactive), 2015/11/09 17:42:41]

typo: the

[clamy, 2015/11/10 11:58:53]

Done.

+  // use-after-free bugs. Should the implementer need to destroy the
+  // WebContents, it should return CANCEL, CANCEL_AND_IGNORE or DEFER and

[nasko, 2015/11/09 17:31:18]

Should we encourage the usage of DEFER if they will be deleting WebContents?

Also, let's clarify that it is the WebContents this throttle is associated with,
not just any WebContents.

[clamy, 2015/11/10 11:58:53]

I think it's more of a special case for when the check may destroy the
WebContents when it's performed. If you know during WillStartRequest that you
will destroy it (asynchronously) then canceling seems more proper.

+  // perform the destrutction asynchronously.

[mnaganov (inactive), 2015/11/09 17:42:41]

typo: destruction

[clamy, 2015/11/10 11:58:53]

Done.

   virtual ThrottleCheckResult WillStartRequest();
 
   // Called when a server redirect is received by the navigation.
+  //
+  // The implementer is responsible for ensuring that the WebContents remain
+  // alive during teh duration of this method. Failing to do so will result in

[mnaganov (inactive), 2015/11/09 17:42:41]

typo: the

[clamy, 2015/11/10 11:58:53]

Done.

+  // use-after-free bugs. Should the implementer need to destroy the
+  // WebContents, it should return CANCEL, CANCEL_AND_IGNORE or DEFER and
+  // perform the destrutction asynchronously.

[mnaganov (inactive), 2015/11/09 17:42:41]

typo: destruction

[clamy, 2015/11/10 11:58:53]

Done.

   virtual ThrottleCheckResult WillRedirectRequest();
 
   // The NavigationHandle that is tracking the information related to this