175881 - DL manager's "Launch File" and "Show in Finder" buttons are not functional with previous download entries

Status: VERIFIED FIXED

(SeaMonkey :: Download & File Handling, defect, P3)

Description

[Chris Petersen]

Build: 2002-10-21-05 branch
Platform: OS X 10.2
Expected Results: "Launch File" and "Show in Finder" buttons should function
What I got: After selecting a previous dl item in the DL window, neither "Launch
File" and "Show in Finder" will function.


Steps to reproduce:

1) Complete a file transfer via the Download manager
2) After this is completed, select the item listed in Download manager
3) Click on "Launch File" or "Show in Finder" button to verify it functions
4) Quit and relaunch application
5) Open DL Manager via Tools menu
6) Select a previous DL item and click on either "Launch File" or "Show in
Finder" button again.
7) Button is no longer functional.

Comment 1

[Place Holder]

I think I have a variation on the same problem
(on Windows XP using Mozilla 1.2)

-I cleared my download manager list and closed the window
-Downloaded another file which reopened but did not focuse the
 download manager
-When I focused the download manager window, the only entry was
 highlighted, but the "action" buttons were not available
-When I downloaded yet another file, all the buttons were now avail
-This was repeatable by always empty and closing the download manager
 window
-I also noted that the first file is out of order while the rest of the
 files stay in order of download, the first file sorts to the bottom
 as if it were the last file downloaded

Comment 2

[Chris Petersen]

This problem is still occuring on the Mach-O (2003-01-23-07) trunk build under
OS X 10.2.3.

Comment 3

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 4

[Paul Wyskoczka]

Nav triage team: over to Jan for a look.

Comment 5

[Ian Neal]

Is this fixed now that patch to bug 132331 has been checked in? BuildID
20030523xx and later have it in. Behaviour now is, if the file doesn't exist,
then those buttons are disabled rather than doing nothing.

Comment 6

[Jan Varga [:janv]]

This is still an issue, working on a fix...

Comment 7

[Jan Varga [:janv]]

Attachment: patch

Comment 8

[Jan Varga [:janv]]

My patch also fixes a regression introduced by fix for bug 191217.
"Launch file" should be hidden on linux.

Comment 9

[jag (Peter Annema)]

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

Hrm, I think I just sr'ed a very similar patch in bug 206441.

Comment 10

[Jan Varga [:janv]]

I suspect, jag will want to change:
file = fileHandler.getFileFromURLSpec(aFilePath);
file = file.QueryInterface(lfIID);
to:
file = fileHandler.getFileFromURLSpec(aFilePath)
                  .QueryInterface(lfIID);

the same for handler/fileHandler
I'll do that if needed (no need to attach a new patch)

Comment 11

[[e-mail]]

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

Wouldn't it be better to cache the file protocol handler?

Also, how difficult would it be to fix the // XXXvarga download manager? Or at
least explain why it isn't consistent :-)

Comment 12

[Jan Varga [:janv]]

>Wouldn't it be better to cache the file protocol handler?
yes, good idea

>Also, how difficult would it be to fix the // XXXvarga download manager? Or at
>least explain why it isn't consistent :-)

Originally, I wanted to fix the download manager (I mean the nsDownloadManager),
but I found out that it would be quite risky change and I doubt it would be
approved for 1.4.
I filed bug 208113 for a better fix.

working on a new patch

Comment 13

[Jan Varga [:janv]]

Attachment: new patch

this patch incorporates gStatusbar change

Comment 14

[Ian Neal]

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

Cancelling old request

Comment 15

[[e-mail]]

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

Comment 16

[Ian Neal]

Shouldn't that now be:
+  var ioService = Components.classes[ioSvcContractID].getService(ioSvcIID);

Comment 17

[Jan Varga [:janv]]

yes, good catch, I'll change it before landing

Comment 18

[Ian Neal]

Best to ask Neil for the review as I'm only 80% sure of the code.

Comment 19

[Jan Varga [:janv]]

Comment on attachment 124826 [details] [diff] [review]
new patch

if I knew it earlier ...

Comment 20

[[e-mail]]

Comment on attachment 124826 [details] [diff] [review]
new patch

Well I'm glad you asked Ian for review because I didn't spot the JS strict
warning.

Comment 21

[jag (Peter Annema)]

Comment on attachment 124826 [details] [diff] [review]
new patch

+  catch(ex) {
+    file = null;
+  }

No need for that, if any of doSomething() fails in |file = doSomething()|, file
won't change.

sr=jag

Comment 22

[Jan Varga [:janv]]

fixed on the trunk

Comment 23

[Asa Dotzler [:asa]]

Comment on attachment 124826 [details] [diff] [review]
new patch

a=asa (on behalf of drivers) for checkin to the 1.4 branch.

Comment 24

[Paul Wyskoczka]

a=adt.  Please land this fix on the 1.4 Branch and add the 1.4fixed keyword.

Comment 25

[Jan Varga [:janv]]

fixed on the branch

Comment 26

[Chris Petersen]

Verified on the Macho trunk build (2003-06-05-08)

Comment 27

[Chris Petersen]

Verified on the 2003-06-05-05 Win32 trunk

Comment 28

[[e-mail]]

> No need for that, if any of doSomething() fails in |file = doSomething()|,
> file won't change.

Although strictly speaking it wouldn't have been initialized...

Comment 29

[Chris Petersen]

Verified on Macho and Win32 branch builds

Comment 30

[henry.ye]

Build: Mozilla1.7
Platform: linux suse
Expected Results: "Launch File" buttons should function
What I got: After selecting a previous dl item in the DL window, "Launch
File"  function.

But, it is no longer functional.