Add a way to cancel deferred navigations in NavigationHandle

content/public/browser/navigation_throttle.h

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_PUBLIC_BROWSER_NAVIGATION_THROTTLE_H_
 #define CONTENT_PUBLIC_BROWSER_NAVIGATION_THROTTLE_H_
 
 #include "content/common/content_export.h"
 
 namespace content {
 class NavigationHandle;
 
 // A NavigationThrottle tracks and allows interaction with a navigation on the
 // UI thread.
 class CONTENT_EXPORT NavigationThrottle {
  public:
   // 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,
   };
 
   NavigationThrottle(NavigationHandle* navigation_handle);
   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
   // navigation.
   NavigationHandle* navigation_handle() const { return navigation_handle_; }
 
  private:
   NavigationHandle* navigation_handle_;
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_BROWSER_NAVIGATION_THROTTLE_H_