Closed Bug 241209 Opened 21 years ago Closed 21 years ago

"Show File Location" and "Launch File" buttons (on download progress dialog) don't work

Categories

(SeaMonkey :: Download & File Handling, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha1

People

(Reporter: masayuki, Assigned: Biesinger)

References

Details

(Keywords: verified1.7)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040420 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040420 On download progress dialog, in the case of download completed, "Open File Location" and "Launch File" buttons don't work. Reproducible: Always Steps to Reproduce: 1. Do "Save Link Target As" on any link. 2. Check the checkbox on download prgress dialog. 3. Click "Open File Location" or "Launch File" button. Actual Results: Those buttons don't work. Expected Results: Those buttons must work fine.
Does the file you've selected still exist in that location? These buttons are disabled if you have selected a file that no longer exists. Appears to work for files that still exist. If this is just that the files you selected don't exist then this bug is invalid. If you don't have permissions to resolve the bug let me know (via a comment on the bug) and I'll resolve it for you.
Forgot to change the component to D/L manager. Apologies for the spam.
Component: Browser-General → Download Manager
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040419, can't see any JS error in JS console.
Component: Download Manager → Browser-General
Errors that appear with Venkman when clicking the launch button: Warning ``reference to undefined property this.targetFile.launch'' [xs] in file ``file:///D:/mozilla/tree6/mozilla/obj-i686-pc-cygwin/dist/bin/components/nsProgressDialog.js'', line 566, character 0. Error ``this.targetFile.launch is not a function'' [xs] in file ``file:///D:/mozilla/tree6/mozilla/obj-i686-pc-cygwin/dist/bin/components/nsProgressDialog.js'', line 566, character 0.
Assignee: general → download-manager
Component: Browser-General → Download Manager
this is the progress dialog, not download manager. hence comment 1 does not apply.
*** Bug 241911 has been marked as a duplicate of this bug. ***
Same problem occurs in Mac OS X as of build 2004042808. Console states: nsProgressDialog::onLaunch failed: TypeError: this.targetFile.launch is not a function
this may be a regression caused by the ftp upload patch... I'll try to investigate this over the next days...
And indeed it is. this.targetFile is never QId to nsILocalFile. Consequently, xpconnect doesn't know the methods launch() and reveal() are available on this object.
Assignee: download-manager → cbiesinger
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8a?
Summary: "Open File Location" and "Launch File" buttons (on download progress dialog) don't work → "Show File Location" and "Launch File" buttons (on download progress dialog) don't work
Attached patch patch (deleted) — Splinter Review
Attachment #147465 - Flags: superreview?(darin)
Attachment #147465 - Flags: review?(neil.parkwaycc.co.uk)
when bug 24867 lands on the 1.7 branch, this will have to land there too
Status: NEW → ASSIGNED
Depends on: 24867
Target Milestone: --- → mozilla1.8alpha
Comment on attachment 147465 [details] [diff] [review] patch sr=darin
Attachment #147465 - Flags: superreview?(darin) → superreview+
Comment on attachment 147465 [details] [diff] [review] patch >+ if (newval instanceof nsIFileURL && newval.file instanceof nsILocalFile) { >+ this.mTargetFile = newval.file.QueryInterface(nsILocalFile); Note that every time you access .file it clones a new one. Just how many file URLs files aren't local files anyway? :-P
Attachment #147465 - Flags: review?(neil.parkwaycc.co.uk) → review+
(In reply to comment #13) > Note that every time you access .file it clones a new one. > Just how many file URLs files aren't local files anyway? :-P oh well, this is not performance-critical (called once per showing a progressdialog) Checking in nsProgressDialog.js; /cvsroot/mozilla/embedding/components/ui/progressDlg/nsProgressDialog.js,v <-- nsProgressDialog.js new revision: 1.37; previous revision: 1.36 done
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Flags: blocking1.8a?
Resolution: --- → FIXED
shouldn't this be landed on 1.7 since bug 24867 has landed on 1.7 per comment #11?
(In reply to comment #15) >bug 24867 has landed on 1.7 it has? doesn't look to me like it did....
okay, sorry, maybe I misunderstood bug 24867 comment #c210 then.
(In reply to comment #17) > okay, sorry, maybe I misunderstood bug 24867 comment #c210 then. that means that bug has permission to get checked in on the 1.7 branch, not that it was already checked in
Did this affect Linux too? Mac and Windows I've branch verified, but Linux, the problem didn't happen 0504 for me (looks like checkin was 0505).
Keywords: verified1.7
OS: Windows XP → All
QA Contact: general → benc
Hardware: PC → All
I don't think that those buttons are enabled for Linux.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: