Clear SDCH information on "Clear browsing data" path.

chrome/browser/net/sdch_dictionary_fetcher.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.
 
 #include "chrome/browser/net/sdch_dictionary_fetcher.h"
 
 #include "base/bind.h"
 #include "base/compiler_specific.h"
 #include "base/message_loop/message_loop.h"
 #include "chrome/browser/profiles/profile.h"
@@ skipping 31 matching lines @@
   if (attempted_load_.find(dictionary_url) != attempted_load_.end()) {
     net::SdchManager::SdchErrorRecovery(
         net::SdchManager::DICTIONARY_ALREADY_TRIED_TO_DOWNLOAD);
     return;
   }
   attempted_load_.insert(dictionary_url);
   fetch_queue_.push(dictionary_url);
   ScheduleDelayedRun();
 }
 
+void SdchDictionaryFetcher::Cancel() {
+  DCHECK(CalledOnValidThread());
+
+  current_fetch_.reset(NULL);
+  weak_factory_.InvalidateWeakPtrs();
+  attempted_load_.clear();
+  std::queue<GURL> trash_queue;
+  fetch_queue_.swap(trash_queue);

[jar (doing other things), 2014/06/11 23:23:49]

nit: (personal style): It is probably safer to first effectively clear the queue
(via your swap technique), and then invalidate the weak pointers, on the *off*
chance that some side effect of the pointer release would induce reentrant
callbacks which examine or test the queue.

I don't think this happens... but it is a personal style issue which sometimes
has saved me (and failure to do so has historically hurt me in some code). 
YMMV.

[Randy Smith (Not in Mondays), 2014/06/12 18:15:45]

Hmmm.  So your comment made me think about ordering, and the conclusions I came
to were:
* I can't see a way in which invalidating weak pointers can result in
re-entrancy, because invalidating weak pointers breaks links to this class
without affecting ownership or deletion semantics.
* I *could* imagine the reset of the URLFetcher resulting in some interesting
re-entrancy.

So I did the URLFetcher reset last, and did the weak pointer invalidation
second-to-last as per your request/in case I'm missing something.  But I'd be
interested in more details about how you think invalidating weak pointers could
result in re-entrancy if you're willing to share.

+}
+
 void SdchDictionaryFetcher::ScheduleDelayedRun() {
   if (fetch_queue_.empty() || current_fetch_.get() || task_is_pending_)
     return;
   base::MessageLoop::current()->PostDelayedTask(FROM_HERE,
       base::Bind(&SdchDictionaryFetcher::StartFetching,
                  weak_factory_.GetWeakPtr()),
       base::TimeDelta::FromMilliseconds(kMsDelayFromRequestTillDownload));
   task_is_pending_ = true;
 }
 
@@ skipping 17 matching lines @@
   DCHECK(CalledOnValidThread());
   if ((200 == source->GetResponseCode()) &&
       (source->GetStatus().status() == net::URLRequestStatus::SUCCESS)) {
     std::string data;
     source->GetResponseAsString(&data);
     manager_->AddSdchDictionary(data, source->GetURL());
   }
   current_fetch_.reset(NULL);
   ScheduleDelayedRun();
 }