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.

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.

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.

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.

when bug 24867 lands on the 1.7 branch, this will have to land there too

Comment on attachment 147465 [details] [diff] [review] patch sr=darin

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

(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

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).

I don't think that those buttons are enabled for Linux.