chrome://downloads updateDateDisplay more often

chrome/browser/resources/downloads/downloads.js

Index: chrome/browser/resources/downloads/downloads.js
diff --git a/chrome/browser/resources/downloads/downloads.js b/chrome/browser/resources/downloads/downloads.js
index 9eac064f8ad58c9a78f704f8378cc97dc306d7a9..3f96887e1f41bcc816028732182ad277bb0756f3 100644
--- a/chrome/browser/resources/downloads/downloads.js
+++ b/chrome/browser/resources/downloads/downloads.js
@@ -104,8 +104,13 @@ Downloads.prototype.updated = function(download) {
     } else {
       this.node_.appendChild(this.downloads_[id].node);
     }
-    this.updateDateDisplay_();
   }
+  // Download.prototype.update may change its nodeSince_ and nodeDate_, so

[asanka, 2012/09/17 16:48:14]

Is nodeSince_ updated for all the download items after a clock adjustment?

[benjhayden, 2012/09/17 17:02:38]

Yes, downloads_dom_handler.cc since_string uses TimeFormat::RelativeDate(),
which calls Time::Now(), which tracks the system clock according to base/time.h.
But no, merely changing the clock doesn't trigger any events that
DownloadsDOMHandler watches for. The next time a download is created or
destroyed, all the items will be updated at once. A single OnDownloadUpdated
event without download creation or deletion might mean that one entry in
chrome://downloads reflects the new time but the rest don't. This fix at least
prevents there from being two 'Today' sections with the same date, though there
may be two 'Today' sections with different dates. I could probably hack some
javascript together to detect same since strings with different dates and call
getDownloads, but I think that the only way to get in this state (after this fix
is in) would be if you changed the system clock while a large file was actually
downloading or a dangerous file was waiting to be confirmed, which seems rare
and not worth the effort.

[asanka, 2012/09/17 17:50:14]

Yeah. I wasn't sure what the intended fix was. It seems there are other places
where we assume that downloads are created in wall clock order, and this issue
is partly about that assumption being false.

Also, it looks like TimeFormat::RelativeDate() will return 'Today' for all dates
that are in the future. So if there is a download in history with a start date
more than a day in the future, that item as well as any downloads that were in
fact started "today" will all get the 'Today' label. So even with this fix,
there would be two "Today" sections. Isn't it?

[benjhayden, 2012/09/17 18:09:42]

I like car analogies, even though I know next to nothing about cars.
This would be like propping your car up on blocks and running it in reverse
until the odometer ran negative. Of course the car wasn't driven -100 miles.
You're just asking it to lie to you.
I suppose we could detect future downloads and change the since string from
Today to 'Pass the sonic screwdriver' or 'Back... to the Future!' or some other
scifi reference.

+  // update all the date displays.
+  // TODO(benjhayden) Only do this if its nodeSince_ or nodeDate_ actually did
+  // change since this may touch 150 elements and Downloads.prototype.updated
+  // may be called 150 times.
+  this.updateDateDisplay_();
 };
 
 /**