95572 - [RFE] Pressing "Launch File" or "Reveal Location" should close the "Saving File" window

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, enhancement)

Description

[Roland]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3+) Gecko/20010810
BuildID:    2001081003

When "Saving File" dialog has completed the download and "Keep this window open
after the download is complete" is checked, the dialog does not close
automatically and [Launch File] and [Reveal Location] get enabled. This is a
nice feature and I have it on by default.
Now when I press either of these buttons - I expect the dialog to be closed and
apropriate action to be executed - The action gets executed but the dialog stays
open until I specifically close it.

Reproducible: Always
Steps to Reproduce:
1. Download
http://ftp.mozilla.org/pub/mozilla/nightly/2001-08-14-12-trunk/mozilla-win32-installer-sea.exe
2. When "Saving File" dialog appears, chheck "Keep this window..." checkbox
3. Wait until download is complete and click on the "Reveal Location" button

Actual Results:  Explorer (I'm running on WinNT) opens in the folder where I
saved the mozilla-win32-installer-sea.exe to.
Saving File dialog is still open and I have to explicitly close it.

Expected Results:  I'd expect the "Saving File" dialog to close after I press
any of the enabled buttons (just as it does in IE).
It seems to be quite logical to assume that when I want to reveal the location
of the downloaded file (or launch it), I don't have no use for "Saving File"
dialog any more and it should be closed automatically.

Im marking it as a RFE, scince it is only a minor annoyance and I can easily
live without it, but nevertheless it makes Moz to feel less polished than IE.

Comment 1

[timeless]

hrm. [win]IE feels less polished than NetPositive.  Actually, to be fair, MacIE 
is better. Both MacIE and NetPositive have real download managers which let you 
reveal in Finder/Tracker and still manage the object in the Download Manager.

Comment 2

[Roland]

Attachment: my proposed patch

Comment 3

[Roland]

Though DL manager would be great, I think it is irrelevant to this bug.

I atached a relevant portion of cvs generated diff as an plaintext to this bug
as a possibile solution (this worked for me).

All I had to do was adding window.close() to functions doOpen() and
doOpenFolder() in helperAppDldProgress.js in toolkit.jar archive.
(sorry for my poor handling of the cvs and diff though)

Comment 4

[Matthew T (active 1999-2002)]

The `Reveal Location' button should be available even when the file hasn't
finished downloading -- once that is fixed, the code which closes the window for
that button would need to be removed. And once we have a download manager, where
you can get Properties windows for long-ago-completed downloads, it won't make
sense to close the window for `Launch File' either, so this whole patch would
end up being undone.

Neither of those are likely to happen for a while, however, so this is a
sensible temporary fix. --> XP Apps: GUI.

Comment 5

[sairuh (rarely reading bugmail)]

mscott/bill/blake, not sure which of you would take this?

Comment 6

[Roland]

Attachment: A patch made with new PatchMaker tool

Comment 7

[Roland]

I made the patch above using Gerv's new PatchMaker tool. 
The patch was made using Mozilla build 2001200203, if it helps

Would anybody review this and get it checked in for me, pliiz ;)

Comment 8

[Bill Law]

Comment on attachment 51855 [details] [diff] [review]
A patch made with new PatchMaker tool

r=law; I'm also setting target milestone and I'll check this in once it has super-review.

Comment 9

[Scott MacGregor]

Comment on attachment 51855 [details] [diff] [review]
A patch made with new PatchMaker tool

sr=mscott

I like this new behavior too.

Comment 10

[sairuh (rarely reading bugmail)]

spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)

Comment 11

[Blake Ross]

--> law, you gonna check this in?

Comment 12

[Bill Law]

Yes, I screwed up setting target milestone so it fell off my radar screen.  Sorry.

Comment 13

[Bill Law]

Fixed

Comment 14

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2001.11.08.0x-comm bits on winnt and mac os 10.1.

n/a to unix/linux due to bug 67001.