[actually nominating for wanted] As shown in this mockup (attached to bug 397655) : https://bugzilla.mozilla.org/attachment.cgi?id=288692 As of bug 405884 (show date and time for each download), all of the user tasks associated with information behind the information button are supported even without the button. See below for the reasoning. Given that fact, the value of having a button here is outweighed by the simplicity we can achieve by removing it. Rationale: No need for the source URL: The two user-tasks associated with seeing the source information are (a) going there and (b) using some part of that information to tell you what the download is. In the first case, we've supported that by making "Go to Source Location" (and copy for good measure) available in the right-click menu, which is a shorter path than viewing, copying, opening a tab, and pasting. In the latter (b), we made this simpler by listing the TLD inline with each download. No need for the local location: The tasks are (a) getting to the download to launch it, and (b) to see where you put it. Double-clicking the row (or, for discoverability, right-clicking) launches the download, so that's (a) covered. As for (b), "Open Containing Folder"/"Show in Finder" is in the right-click menu. No need for the date/time: As of bug 405884, the date/time is put in a location that's better suited to its use in helping users find the downloads that they're looking for. In other words, we've supported the user tasks (in fact, made them quicker!) while streamlining the UI.

FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility point of view.

(In reply to comment #1) > FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility > point of view. > Partial retraction, if the same info's available in context menu: Context menu can be accessed via Shift-F10 (or via Menu key on 104-key keyboards). Discoverability may remain an issue.

Info button is gone.

Clear up the info button functionality, UI, styling.

(In reply to comment #1) > FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility > point of view. a11y bugs are being addressed in another bug (there's about 20 DM bugs being actively worked on, and the comments are in one of them. Sadly, I don't know which offhand...).

Comment on attachment 291536 [details] [diff] [review] v1 >- >-// If the user has interacted with the window in a significant way, we should >-// not auto-close the window. Tough UI decisions about what is "significant." >-var gUserInteracted = false; > > // These strings will be converted to the corresponding ones from the string > // bundle on startup. > let gStr = { > paused: "paused", > statusFormat: "statusFormat2", >@@ -231,13 +226,13 @@ function autoRemoveAndClose(aDownload) > // opened by the download process, rather than by the user, it should > // auto-close if the pref is set that way. If the user opened it themselves, > // it should not close until they explicitly close it. > var autoClose = pref.getBoolPref(PREF_BDM_CLOSEWHENDONE); > var autoOpened = > !window.opener || window.opener.location.href == window.location.href; >- if (autoClose && autoOpened && !gUserInteracted) { >+ if (autoClose && autoOpened) { please don't remove this. It's rather important! Also, update http://mxr.mozilla.org/seamonkey/source/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css r=sdwilsh with these fixed.

(In reply to comment #5) > (In reply to comment #1) > > FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility > > point of view. > a11y bugs are being addressed in another bug (there's about 20 DM bugs being > actively worked on, and the comments are in one of them. Sadly, I don't know > which offhand...). Looks like I was thinking of Bug 357540.

(In reply to comment #0) > No need for the date/time: > As of bug 405884, the date/time is put in a location that's better suited to > its use in helping users find the downloads that they're looking for. I disagree completely with this. This _removes_ my ability to see the exact date/time for when I downloaded something. I'm now stuck with "Yesterday", "Tuesday", etc. What about the hour and minute? I find that extra tidbit of info extremely useful. I would be ok with it if that same info was included in the normal view (e.g., "Tuesday, 3:12pm" instead of just "Tuesday"), but without that, removing the info button is a regression in functionality and usefulness.

(In reply to comment #8) > I disagree completely with this. This _removes_ my ability to see the exact > date/time for when I downloaded something. I'm now stuck with "Yesterday", > "Tuesday", etc. What about the hour and minute? I find that extra tidbit of > info extremely useful. I would be ok with it if that same info was included in > the normal view (e.g., "Tuesday, 3:12pm" instead of just "Tuesday"), but > without that, removing the info button is a regression in functionality and > usefulness. Sorry, but I think we are going to stick with this for Firefox 3 (unless there's a massive outcry after B3). You are more than welcome to make an Add-on to get it back.

r+ sdwilsh (In reply to comment #6) > >-var gUserInteracted = false; > >- if (autoClose && autoOpened && !gUserInteracted) { > please don't remove this. It's rather important! Restored the gUserInteracted stuff. > Also, update > http://mxr.mozilla.org/seamonkey/source/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css Updated to remove info stuff.

(In reply to comment #9) > Sorry, but I think we are going to stick with this for Firefox 3 (unless > there's a massive outcry after B3). You are more than welcome to make an > Add-on to get it back. Sorry, but I want a UX answer to my statement in comment #8, and I'd prefer it before this patch lands.

(In reply to comment #11) So, about this: "I disagree completely with this. This _removes_ my ability to see the exact date/time for when I downloaded something. I'm now stuck with "Yesterday", "Tuesday", etc. What about the hour and minute? I find that extra tidbit of info extremely useful. I would be ok with it if that same info was included in the normal view (e.g., "Tuesday, 3:12pm" instead of just "Tuesday"), but without that, removing the info button is a regression in functionality and usefulness." We removing some detail, yes, but I disagree that it's a regression in usefulness. It's not free, in terms of a user's information-processing time, to include extra information that is likely to be useful only in unusual circumstances. By removing it, we make the information that is more likely of use -- a sense, with sufficient granularity, of when the download was downloaded -- much more prominent and scannable. That said, I'm curious to hear about your scenario where that level of detail is valuable. Also, in The Future, when we have a Downloads section in Places Organizer, we could certainly list the exact date and time. The task in that case won't be scanning through a list, so there would be no downside. > (In reply to comment #9) > > Sorry, but I think we are going to stick with this for Firefox 3 (unless > > there's a massive outcry after B3). You are more than welcome to make an > > Add-on to get it back. > > Sorry, but I want a UX answer to my statement in comment #8, and I'd prefer it > before this patch lands. >

Checking in toolkit/locales/en-US/chrome/mozapps/downloads/downloads.dtd; /cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.dtd,v <-- downloads.dtd new revision: 1.21; previous revision: 1.20 done Checking in toolkit/mozapps/downloads/content/download.xml; /cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v <-- download.xml new revision: 1.47; previous revision: 1.46 done Checking in toolkit/mozapps/downloads/content/downloads.js; /cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v <-- downloads.js new revision: 1.116; previous revision: 1.115 done Checking in toolkit/mozapps/downloads/content/downloads.xul; /cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.xul,v <-- downloads.xul new revision: 1.40; previous revision: 1.39 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.3; previous revision: 1.2 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.21; previous revision: 1.20 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.25; previous revision: 1.24 done

https://litmus.mozilla.org/show_test.cgi?id=4569 and https://litmus.mozilla.org/show_test.cgi?id=4551 have both been smitten. in-litmus+

Verified FIXED using: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007123104 Minefield/3.0b3pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007123104 Minefield/3.0b3pre --and-- Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2007123105 Minefield/3.0b3pre

So, info bubble has been removed?

(In reply to comment #16) > So, info bubble has been removed? yes