Restart counters when the MD CBD dialog is reopened.

chrome/browser/ui/webui/settings/settings_clear_browsing_data_handler.cc

Index: chrome/browser/ui/webui/settings/settings_clear_browsing_data_handler.cc
diff --git a/chrome/browser/ui/webui/settings/settings_clear_browsing_data_handler.cc b/chrome/browser/ui/webui/settings/settings_clear_browsing_data_handler.cc
index b03fb3741eccc243c8f510eadc88854673cd8b27..3d131841fe47e5ff2cbc4222a29d8676b4775c41 100644
--- a/chrome/browser/ui/webui/settings/settings_clear_browsing_data_handler.cc
+++ b/chrome/browser/ui/webui/settings/settings_clear_browsing_data_handler.cc
@@ -272,6 +272,10 @@ void ClearBrowsingDataHandler::HandleInitialize(const base::ListValue* args) {
   OnStateChanged();
   RefreshHistoryNotice();
 
+  // Restart the counters if the dialog is reopened.
+  for (const auto& counter : counters_)
+    counter->Restart();

[tommycli, 2016/12/16 17:39:14]

how much performance penalty is it to create the counter in AllowJavascript and
then immediately restart it here?

Do counters kick off any I/O operations on a separate thread for instance?

[msramek, 2017/01/03 13:56:39]

Oops, I didn't realize that AllowJavascript() is called in HandleInitialize()
*before* we do the restart. That would be indeed a duplication. Removing
Restart() from AddCounter() should do the trick. In the last patchset, Restart()
is called exactly once for each counter each time the dialog is opened.

And yes, counting is done asynchronously, for example reading the cache index on
the IO thread, or the passwords database on the DB thread.

+
   ResolveJavascriptCallback(
       *callback_id,
       *base::Value::CreateNullValue() /* Promise<void> */);