Add new UMA stats to get a handle on Downloads UI Usage

content/browser/download/download_manager.h

Index: content/browser/download/download_manager.h
diff --git a/content/browser/download/download_manager.h b/content/browser/download/download_manager.h
index 4a8c4a0686a44878e84c590dfe70c490154f3929..2a39f7441485060736db86dd2dbda250c369273e 100644
--- a/content/browser/download/download_manager.h
+++ b/content/browser/download/download_manager.h
@@ -263,6 +263,9 @@ class CONTENT_EXPORT DownloadManager
   // DownloadManagerDelegate::ShouldStartDownload and now is ready.
   void RestartDownload(int32 download_id);
 
+  // Mark the download opened in the persistent store.
+  void MarkDownloadOpened(DownloadItem* download);

[Randy Smith (Not in Mondays), 2011/09/28 19:41:55]

I thought this was being removed?

[benjhayden, 2011/09/28 20:29:39]

I removed DownloadDatabase::MarkDownloadRemoved and
HistoryService::MarkDownloadRemoved, but there isn't a DownloadManager method
that just calls delegate->UpdateEntry(). All the other methods that call
delegate->UpdateEntry() also do a bunch of other stuff, depending on who calls
them. MarkDownloadOpened() will also implement DownloadOpensOutstanding in the
next patch set.

[Randy Smith (Not in Mondays), 2011/09/30 15:57:21]

Hmmm.  Ok.  From a pure functionality approach, I'd rather have a blunt hammer
(when something changes in the DownloadItem, it calls
DownloadManager::DownloadUpdated(), which passes the change along to the history
system.  Or even better, the DM is an observer of the DI, and just does the
automatic pass along if the DI is a persistent DI).  But that makes collecting
the opens outstanding statistic hard.  Still, if you'd be willing, keep an eye
out for ways to make this type of transformation; I think it would simplify the
DI->DM interface and reduce the size of the DM interface.  

(I'm tempted to request a "RecordOpensOustanding" method on the DM that the DI
calls on this transition, and then just switching the actual functionality over
to one of the sketches above, and if you want to that, feel free.  Of you can
leave it like this and keep a lookout for future improvements--your call.)

[benjhayden, 2011/10/03 20:54:39]

The DI could implement RecordOpensOutstanding() inline using DM->Search(). This
feels just a little dirty.
DM::MarkDownloadOpened() fits with DM's current style, right? I think I'd rather
handle big refactors like this in batch CLs.

I can think of a few different ways of reorganizing the DM/DI interfaces. Want
to have a meeting at some point? Is there something already scheduled for
tomorrow's team meeting?

[Randy Smith (Not in Mondays), 2011/10/04 18:34:31]

Agreed.
Fair enough.  I agree that we should try and keep interfaces internally
self-consistent and change them all at once.  

(OKRs is the primary thing on the agenda for tomorrow's meeting :-}.  Maybe next
week.)

+
   // Checks whether downloaded files still exist. Updates state of downloads
   // that refer to removed files. The check runs in the background and may
   // finish asynchronously after this method returns.