Fix two URLRequestJob subclasses that didn't support cancellation

components/about_handler/url_request_about_job.cc

 // Copyright (c) 2012 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.
 
 // Simple implementation of about: protocol handler that treats everything as
 // about:blank.  No other about: features should be available to web content,
 // so they're not implemented here.
 
 #include "components/about_handler/url_request_about_job.h"
 
@@ skipping 12 matching lines @@
 }
 
 void URLRequestAboutJob::Start() {
   // Start reading asynchronously so that all error reporting and data
   // callbacks happen as they would for network requests.
   base::ThreadTaskRunnerHandle::Get()->PostTask(
       FROM_HERE,
       base::Bind(&URLRequestAboutJob::StartAsync, weak_factory_.GetWeakPtr()));
 }
 
+void URLRequestAboutJob::Kill() {
+  URLRequestJob::Kill();
+  weak_factory_.InvalidateWeakPtrs();

[davidben, 2015/10/08 16:16:36]

Nit: Completely doesn't matter here, but I've seen both orders. My first thought
would be that InvalidateWeakPtrs() should be first, to maintain the invariant
that there is no point in time that the WeakPtr is alive and the URLRequestJob
killed. Kinda like how you destructor subclass before superclass. Thoughts?

(Ditto for the other file.)

[mmenke, 2015/10/08 16:20:42]

Makes sense.  That also the reverse of construction order.  Done (x2).

+}
+
 bool URLRequestAboutJob::GetMimeType(std::string* mime_type) const {
   *mime_type = "text/html";
   return true;
 }
 
 URLRequestAboutJob::~URLRequestAboutJob() {
 }
 
 void URLRequestAboutJob::StartAsync() {
   NotifyHeadersComplete();
 }
 
 }  // namespace about_handler