The "Properties" view for download is currently implemented as a modal sheet on OSX and a window in w32 with some strange dependencies/behaviours based on when the parent window closes (see bug 321914 for more on the OSX problems). A better way to expose this information would be to add a lightweight UI function that expands the information listed in the Download Manager to reveal the extra properties. Something like: .---------------------------------------------. | someFile _Open_ | | _Remove_ | | _Details_| |---------------------------------------------| | someOtherFile _Open_ | | _Remove_ | | from: _http://www.foo.com/_ | | to : _~/fooplace_ | | completed on Feb 14th, 2009 _Hide Details_| |---------------------------------------------| | | : : (items in _text_ are displayed as hyperlinks, and perform the listed action or go to the listed place)

I'd like to see the to: _~/fooplace_ line under the filename when the details are hidden.

w/Pam's suggestion ..: .---------------------------------------------. | someFile _Open_ | | Done (to: _~/fooplace_) _Remove_ | | _Details_| |---------------------------------------------| | someOtherFile _Open_ | | _Remove_ | | from: _http://www.foo.com/_ | | to : _~/fooplace_ | | completed on Feb 14th, 2009 _Hide Details_| |---------------------------------------------| | | : : I'm assuming that in the non-details state, the text beneath "someFile" would be grey, much as the "Done" label is right now. I can see some advantage to this system, but really, my gut says that the underlying file system is something we want to abstract away from the user in the primary UI, not present to them front and centre.

In normal use, I agree that keeping the app and the filesystem separate is best. No reason for a user to know where extensions are installed or the cache lives in the general course of things. But downloading something strikes me as fundamentally tied to the file system, and at that point I'd like it to be as transparent/convenient as possible. FWIW, I'd probably shuffle things just a little, so the "to:" line and "Details" link don't move when details are shown or hidden: .---------------------------------------------. | someFile _Open_ | | _Remove_ | | Done (to: _~/fooplace_) _Details_| |---------------------------------------------| | someOtherFile _Open_ | | _Remove_ | | Done (to: _~/fooplace_) _Hide Details_| | from: _http://www.foo.com/_ | | completed on Feb 14th, 2009 | |---------------------------------------------| | | : :

Would you show the full path, or just the name of the folder where the file was downloaded to? Showing a full path and making it clickable etc could make things look clumsy/cluttered, especially if users don't have a huge hierarchy.

Do we need to show any of the path at all when the details are hidden? Even making the name of the item itself a clickable link to reveal it in the file system would serve the functional purpose... although it's not very apparent.

If I clicked on the name of the file, I would expect that file to be opened with the default handler, since that's what happens when I click on a named object anywhere else in my OS. Not to mention that a double-click currently launches the file, so it would be odd for a single click to open the finder. Perhaps instead of "Done" we should have the text read "Show in Explorer/Finder"? .---------------------------------------------. | someFile _Open_ | | _Remove_ | | _Show in Explorer_ _Details_| |---------------------------------------------| | someOtherFile _Open_ | | _Remove_ | | _Hide Details_| | to: ~/long/path/someOtherFile | | from: _http://www.foo.com/_ | | completed on Feb 14th, 2009 | |---------------------------------------------| | | : : To be honest, though, I'm still not convinced that we need to make this function available through anything other than right-click or showing the details. It seems like precisely the type of implementation detail that a download manager is meant to hide from users.

Although my preference would be for easier access, I recognize that I'm not a typical user, and I'd be content if it were available in the details. As a general rule, though, right-click might as well not exist on the Mac. Interesting thought. Is where a download was saved an implementation detail? I would have called it an integral part of the download. Hiding it too much leads to me having a lot of stuff on my hard drive that I don't recognize or remember.

While you're at it, I have a small suggestion for the download manager - change the word 'Remove' to 'Clear'. I still hesitate, to this day, before clicking 'Remove' as I frequently forget whether it removes it from the download list, or the file from my hard drive. 'Clear' more strongly suggests the former.

That would depend entirely on whether we want to actually remove the file itself, which is an open question.

Is it? We don't remove it now, which I think is the most sensible behaviour. People generally don't expect their download manager to remiove their files, they can do it themselves via their OS.

That's a strong assertion that I doubt would hold up. If I have something showing a list of files, and a UI element to Remove the file, I might easily assume that I'm removing the file, not the entry. And whether people expect that right now, it's a valuable timesaver to those who want it.

(In reply to comment #11) > That's a strong assertion that I doubt would hold up. If I have something > showing a list of files, and a UI element to Remove the file, I might easily > assume that I'm removing the file, not the entry. Exactly my point. > And whether people expect > that right now, it's a valuable timesaver to those who want it. And a big nuisance to those who don't.

For those following along at home, Jeremy is talking about a "Clear" action, and mconnor is talking about a "Delete" action. Regardless, Jeremy is right that "Remove" is ambiguous, and so we should really probably go one way or the other here. Also regardless, it's a little OT for this bug, so hopefully Jeremy will file a new one and cc everyone so we can continue the discussion elsewhere ...

Mike: I proposed that in irc.mozilla.org #mozilla, but I was pointed to this bug as being a more appropriate place to bring it up.

Didn't your mother warn you about believing strange people in internet chat rooms? This bug is about adding the download properties, which involves new code. Changing the label of that item would be a smaller fix, and should be a seperate bug (although, I suppose, if we switch it to mean "delete", then it's a larger fix again ... either way ...)

An RFE to change one word in the code? mconnor could we please have your advice on whether this can be bundled into some bug like this?

What we do with the Remove item is a separate bug. If it was an absolute given that you were right and there was no need for discussion as to what function is most useful, then sure, we could lump it in with this bug. However, given that this obviously isn't the case, a separate bug is the right thing. I'm actually surprised that clarification was needed for that...

Oh yeah, oh sure. And the only one who actually disagreed with my idea was..? :-D

Both Mike and I, fwiw. That's why I told you to put it in a separate bug.

New bug #330139 filed.

Fixed by Bug 388517.

I'll be tracking specific UI issues already (and have been, frankly), so this bug can be verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007081409 Minefield/3.0a8pre (and mac/linux).