[actually nominating for wanted] As shown in this mockup (attached to bug 397655) : https://bugzilla.mozilla.org/attachment.cgi?id=288692 Showing the date/time of completion for each download will help users who know roughly when they downloaded the sought-after file by letting them scan down the list and narrow their visual searches. At the moment, in Minefield, this information is currently hidden behind an (i) button.

For a "first order implementation", we could just set the time when the download manager builds the list (open/search) and when the download finishes. Probably shouldn't worry too much about the day changing and download manager open for long times...

Is there a way to grab the month name? Javascript has a Date object that can use the OS's date string, but that's only for the whole date like... xp: Wednesday, November 28, 2007 7:39:22 PM os x: Wed Nov 28 19:39:22 2007 Not sure about other languages.. but do we want to use the OS formatting or use a consistent one across Firefox? sdwilsh: Want to take a stab at the xml/xul? We'll want to separate the button hbox and put it on a separate second row so that the first row with the time doesn't make it fat and unnecessarily crop other stuff.

Where should text crop (first?) [See the lower downloads.] Right now it crops the name and never crops the date/time.

A quickie patch.. for done and canceled.. doesn't cover failed, etc. types. Started removing the buttons to make space for the date/time. sdwilsh: I think I figured out the flex, box, things... hehe ran into issues where target text wouldn't crop. (Am I on the right track?)

Made the date/time center on the same vertical level as the file name.. same for the buttons. The buttons are back for now as there's a separate bug that will remove them. Text crops for both name and time now, but at different rates.. favoring the name because there's less to crop of the time.

Use a spacer to push the labels to the edges while allowing the text to flex/crop. Same thing for done, canceled, failed, blocked.

After some discussion with some other UX types and looking at what's done elsewhere, I think an even simpler and more compact scheme would be as follows: - if the download date is today, list just the time (that it was today is implied) (ie. 3:45 PM) - if it was yesterday, just say "Yesterday" (the exact time of day isn't as useful before the current day) - from 2 days ago 7 days ago, go with the name of the weekday (ie. Tuesday) - any further in the past (ie. one week ago and earlier), and we go with a Month & Day listing, ie. November 21 This should all be easier for users to parse than the mm/dd/yy formats, and should help people use the info they know ("I downloaded that thing this morning / yesterday / on Monday") a little quicker. It also saves room.

Switched to Date.toLocaleFormat to get the weekday and display "month date". For the binding stuff.. basically switched it to 2 rows with things placed on each end instead of 2 columns: one fat one skinny.

Should the date/time never be cropped now that they should be pretty short? Or I could just try weighting the time to be even less likely to be cropped.

No cropping of the date/time.

(In reply to comment #10) Yeah, given how short (and information dense) they are, it'd be odd to crop them. I like this version. > Created an attachment (id=291336) [details] > screenshot of v2 + no date crop > > No cropping of the date/time. >

(In reply to comment #11) Just one more small issue though -- it looks, from the download list, like the current day is Monday (or later), in which case we shouldn't be listing the _last_ monday as "Monday" but as "November xx" (see listing third from the bottom). We should only use weekday names as far back as the Tuesday so that there's no confusion. > (In reply to comment #10) > > Yeah, given how short (and information dense) they are, it'd be odd to crop > them. I like this version. > > > > Created an attachment (id=291336) [details] [details] > > screenshot of v2 + no date crop > > > > No cropping of the date/time. > > >

Changed to no cropping and stopping 1 day before a whole week -- 6 days before today before switching to Month Date.

Screenshot of maybe more realistic download names and such ;) At least for me.. not using a test profile. :p

Comment on attachment 291448 [details] [diff] [review] v2.1 >+yesterday=Yesterday Can we get a note stating what this is used for as well please. This is all getting really complicated, and I want this to be easier on localizers. > /** >+ * Updates the time that gets shown for completed download items >+ * >+ * @param aItem >+ * The richlistitem that has various download attributes. >+ */ nit: "The richlistitem representing a download in the UI" >+function updateTime(aItem) >+{ >+ // Don't bother updating for things that aren't finished >+ if (aItem.inProgress) >+ return; This doesn't apply to downloads in the scanning state - is this OK for you still? I'm not sure if that has an endTime attribute. >+ } else if (today - end < 24 * 60 * 60 * 1000) { nit: parens around the numbers please >+ } else if (today - end < 6 * 24 * 60 * 60 * 1000) { ditto >+ } else { >+ // Download must have been from some time ago.. show month/day >+ let month = end.toLocaleFormat("%B"); >+ let date = end.toLocaleFormat("%d"); >+ dateTime = replaceInsert(gStr.monthDate, 1, month); >+ dateTime = replaceInsert(dateTime, 2, date); it's a shame that toLocaleString doesn't do what we want here :( you also need to update gnomestripe's theme since it's on it's own now. r=sdwilsh with comments addressed.

(In reply to comment #15) > >+ // Don't bother updating for things that aren't finished > >+ if (aItem.inProgress) > >+ return; > This doesn't apply to downloads in the scanning state If this lands after bug 392097, SCANNING will be treated as inProgress.

So I saw :p

(In reply to comment #15) > (From update of attachment 291448 [details] [diff] [review]) > >+yesterday=Yesterday > Can we get a note stating what this is used for as well please. Commented. > >+ * @param aItem > >+ * The richlistitem that has various download attributes. > >+ */ > nit: "The richlistitem representing a download in the UI" Fixed. (Now I wonder how long it'll take to be consistent aItem vs aDownload..) > >+ // Don't bother updating for things that aren't finished > >+ if (aItem.inProgress) > >+ return; > This doesn't apply to downloads in the scanning state - is this OK for you > still? I'm not sure if that has an endTime attribute. Even if it does update, this is an optimization because scanning state's xml binding doesn't use dateTime. > >+ } else if (today - end < 24 * 60 * 60 * 1000) { > >+ } else if (today - end < 6 * 24 * 60 * 60 * 1000) { > nit: parens around the numbers please Added parens around (24...1000) and (6...1000) > you also need to update gnomestripe's theme since it's on it's own now. Added the size for dateTime

Back from India, sorry for the lag. Is toLocaleFormat really what we want? It's giving OS locale, not Firefox locale, i.e., on my German XP with an en-US nightly, new Date().toLocaleFormat('%A') Freitag it returns a German weekday.

Checking in toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties; /cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties,v <-- downloads.properties new revision: 1.18; previous revision: 1.17 done Checking in toolkit/mozapps/downloads/content/download.xml; /cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v <-- download.xml new revision: 1.43; previous revision: 1.42 done Checking in toolkit/mozapps/downloads/content/downloads.js; /cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v <-- downloads.js new revision: 1.110; previous revision: 1.109 done Checking in toolkit/themes/gnomestripe/mozapps/downloads/downloads.css; /cvsroot/mozilla/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css,v <-- downloads.css new revision: 1.2; previous revision: 1.1 done Checking in toolkit/themes/pinstripe/mozapps/downloads/downloads.css; /cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloads.css,v <-- downloads.css new revision: 1.20; previous revision: 1.19 done Checking in toolkit/themes/winstripe/mozapps/downloads/downloads.css; /cvsroot/mozilla/toolkit/themes/winstripe/mozapps/downloads/downloads.css,v <-- downloads.css new revision: 1.24; previous revision: 1.23 done

(In reply to comment #19) > Back from India, sorry for the lag. > > Is toLocaleFormat really what we want? It's giving OS locale, not Firefox > locale, i.e., on my German XP with an en-US nightly, > > new Date().toLocaleFormat('%A') > Freitag > > it returns a German weekday. Please file a follow-up bug if you don't think this is the right behavior.

Verified FIXED using: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007121704 Minefield/3.0b3pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007121704 Minefield/3.0b3pre and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2007121705 Minefield/3.0b3pre with data ranging from today to over a week ago, and following the recommended specification in comment 7.

https://litmus.mozilla.org/show_test.cgi?id=5060 in-litmus+