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

chrome/browser/history/history_types.h

Index: chrome/browser/history/history_types.h
diff --git a/chrome/browser/history/history_types.h b/chrome/browser/history/history_types.h
index ff4741d8c0525f4dba26e65d55a7fff8e4c3676c..b8598d4a21c3eb98ed6f826b24d45dbd40016578 100644
--- a/chrome/browser/history/history_types.h
+++ b/chrome/browser/history/history_types.h
@@ -739,6 +739,20 @@ struct FaviconData {
   history::IconType icon_type;
 };
 
+// The DownloadItem fields that are persisted and may change, which is a subset
+// of DownloadPersistentStoreInfo.
+// TODO(benjhayden): Add filepath and unify UpdateDownload{,Path}().
+struct DownloadItemData {

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

Is there a reason not to use DownloadPersistentStoreInfo?  It was originally
(six months ago :-}) intended to communication with the history DB and to
include everything that the DownloadItem gets from the history DB.

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

DownloadItemData isn't what the DownloadItem gets from the db, it's what the db
gets from the item as the item changes. The url, referrer, and start_time don't
change, so it seems like it would be misleading to call UpdateEntry with a
struct that contains them. I can imagine being surprised whether UpdateEntry
updates those fields or not.

That's the reason not to use DPSI, but I understand the desire to minimize code,
so LMK if that reason is compelling or if I should use DPSI anyway.

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

I think I'd rather use DPSI.  We're already using it in two different ways (pass
information down to the DB for creation, pass all rows back from the DB) and the
values that are significant and not are different in those two cases (db id is
ignored in the first case and not in the second).  I'm inclined to suggest that
you put in debug only code that confirms that the non-mutable fields don't
change on update, and comment the structure with what's mutable and what's not. 
But maybe someday we'll want to mutate the fixed fields :-}.

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

Done.

+  DownloadItemData();
+  ~DownloadItemData();
+
+  int64 received_bytes;
+  int32 state;
+  base::Time end_time;
+  bool opened;
+  DownloadID db_handle;
+};
+
 }  // namespace history
 
 #endif  // CHROME_BROWSER_HISTORY_HISTORY_TYPES_H_