Closed
Bug 408565
Opened 17 years ago
Closed 17 years ago
Menu items "Open Containing Folder" / "Show in Finder" shouldn't be grayed out for in-progress/paused downloads
Categories
(Toolkit :: Downloads API, defect)
Toolkit
Downloads API
Tracking
()
VERIFIED
FIXED
mozilla1.9beta3
People
(Reporter: whimboo, Assigned: Mardak)
References
Details
Attachments
(1 file, 1 obsolete file)
2.27 KB,
patch
|
Mardak
:
review+
beltzner
:
ui-review+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
With the check-in of the patches on bug 403704 and bug 403707 we match the latest spec for in-progress/paused downloads. But the menu item "Open Containing Folder" / "Show in Finder" is grayed out.
We should also enable the item while a download isn't finished yet. As I can see on the latest mockup the item isn't disabled:
http://people.mozilla.com/~madhava/files/downloadmanager/download%20manager%202007-11-14.png
Flags: blocking-firefox3?
Comment 1•17 years ago
|
||
How are you downloading this? It's quite possible that the file doesn't yet exist, so it should be grayed out.
Assignee | ||
Comment 2•17 years ago
|
||
Well, I figured we could at least show the directory. Is there a way to reveal a file and have the directory shown but not the file selected? Is that the default behavior?
This would allow the user to see the directory the partial file is being downloaded as well as be ready when the file finishes.
Reporter | ||
Comment 3•17 years ago
|
||
(In reply to comment #1)
> How are you downloading this? It's quite possible that the file doesn't yet
> exist, so it should be grayed out.
It opens the folder where the file is download to. We don't open the file with this menu item. So why preventing the user to open the folder? Edward still points out all I wanted to say.
Assignee | ||
Comment 4•17 years ago
|
||
Make it always usable and have it do the right function. The original code was causing issues on OS X prompting for an application to handle it... so I made it do launch on the parent.
Reporter | ||
Comment 5•17 years ago
|
||
Is it right, that the return value of onDownloadDblClick is used to enable/disable the context menu entry? It's really hard to bind both things together. Edward, can you create a cvs diff?
Assignee | ||
Comment 6•17 years ago
|
||
I didn't understand either of those 2 questions.. ??
onDownloadDblClick doesn't return anything and a command is enabled/disabled with gDownloadViewController's isCommandEnabled function.
cvs diff of what? instead of the hg diff patch that I attached?
Reporter | ||
Comment 7•17 years ago
|
||
Sorry, I missed the "@@ -669,13 +678,12 @@ var gDownloadViewController = {" line and thought your patch changes code within onDownloadDblClick(aEvent). But now it's clear. Yes, I meant cvs instead of hg but I'll wait until it's fixed now.
Comment 8•17 years ago
|
||
Comment on attachment 293484 [details] [diff] [review]
v1
>+ // "Double click" the parent directory to show where the file should be
>+ parent.launch();
parent should be a nsIFile, so you'll need to QI it to nsILocalFile to be able to call launch.
r=sdwilsh with that fixed.
Attachment #293484 -
Flags: review?(comrade693+bmo) → review+
Assignee | ||
Comment 9•17 years ago
|
||
It works without QIing.. so I just add in.. ?
let parent = f.parent.QueryInterface(Ci.nsILocalFile)
Assignee | ||
Comment 10•17 years ago
|
||
(In reply to comment #8)
> >+ parent.launch();
> parent should be a nsIFile, so you'll need to QI it to nsILocalFile to be able
> to call launch.
Added in QueryInterface.
Attachment #293484 -
Attachment is obsolete: true
Attachment #293624 -
Flags: review+
Attachment #293624 -
Flags: approval1.9?
Comment 11•17 years ago
|
||
I don't understand why that works, but as far as I know we need the QI!
Comment 12•17 years ago
|
||
Comment on attachment 293624 [details] [diff] [review]
v1.1
Just checking with the man, though I think that this is right ...
Attachment #293624 -
Flags: ui-review?(madhava)
Updated•17 years ago
|
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
Comment 13•17 years ago
|
||
Comment on attachment 293624 [details] [diff] [review]
v1.1
a=beltzner for 1.9, and I'm pretty sure it's the right thing to do from the UI perspective
Attachment #293624 -
Flags: ui-review?(madhava)
Attachment #293624 -
Flags: ui-review+
Attachment #293624 -
Flags: approval1.9?
Attachment #293624 -
Flags: approval1.9+
Assignee | ||
Comment 14•17 years ago
|
||
Checking in toolkit/mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v <-- downloads.js
new revision: 1.119; previous revision: 1.118
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: blocking-firefox3- → blocking-firefox3?
Resolution: --- → FIXED
Assignee | ||
Updated•17 years ago
|
Flags: blocking-firefox3? → in-litmus?
Target Milestone: --- → Firefox 3 M11
Flags: in-litmus? → in-litmus+
Reporter | ||
Comment 16•17 years ago
|
||
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121905 Minefield/3.0b3pre
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•