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

Status: RESOLVED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

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.

Comment 1

[Bruce Davidson]

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.

Comment 2

[Bruce Davidson]

Forgot to change the component to D/L manager. Apologies for the spam.

Comment 3

[Frank Wein [:mcsmurf]]

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.

Comment 4

[Frank Wein [:mcsmurf]]

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.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

this is the progress dialog, not download manager. hence comment 1 does not apply.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 241911 has been marked as a duplicate of this bug. ***

Comment 7

[Scott Field]

Same problem occurs in Mac OS X as of build  2004042808.
Console states: nsProgressDialog::onLaunch failed: TypeError:
this.targetFile.launch is not a function

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

this may be a regression caused by the ftp upload patch...

I'll try to investigate this over the next days...

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 12

[Darin Fisher]

Comment on attachment 147465 [details] [diff] [review]
patch

sr=darin

Comment 13

[[e-mail]]

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

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

(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

Comment 15

[Kai de Leeuw]

shouldn't this be landed on 1.7 since bug 24867 has landed on 1.7 per comment #11?

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #15)
>bug 24867 has landed on 1.7 

it has? doesn't look to me like it did....

Comment 17

[Kai de Leeuw]

okay, sorry, maybe I misunderstood bug 24867 comment #c210 then.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

(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

Comment 19

[benc]

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

Comment 20

[[e-mail]]

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