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

VERIFIED FIXED in mozilla0.9.6

Status

Core Graveyard
File Handling
--
enhancement
VERIFIED FIXED
17 years ago
2 years ago

People

(Reporter: Roland, Assigned: Bill Law)

Tracking

Trunk
mozilla0.9.6

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
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.
(Reporter)

Comment 2

17 years ago
Created attachment 46054 [details]
my proposed patch
(Reporter)

Comment 3

17 years ago
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

17 years ago
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.
Assignee: mpt → blake
Status: UNCONFIRMED → NEW
Component: User Interface Design → XP Apps: GUI Features
Ever confirmed: true
Keywords: patch, review
OS: Windows NT → All
QA Contact: zach → sairuh
Hardware: PC → All
Summary: [RFE] Pressing "Launch File" or "Reveal Location" should close the "Saving File" dialog → [RFE] Pressing "Launch File" or "Reveal Location" should close the "Saving File" window
mscott/bill/blake, not sure which of you would take this?
(Reporter)

Comment 6

17 years ago
Created attachment 51855 [details] [diff] [review]
A patch made with new PatchMaker tool
(Reporter)

Comment 7

17 years ago
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 ;)
Blocks: 78106
Keywords: mozilla0.9.6
(Assignee)

Comment 8

17 years ago
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.
Attachment #51855 - Flags: review+

Comment 9

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

sr=mscott

I like this new behavior too.
Attachment #51855 - Flags: superreview+
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. :)
Component: XP Apps: GUI Features → File Handling

Comment 11

17 years ago
--> law, you gonna check this in?
Assignee: blakeross → law
(Assignee)

Comment 12

17 years ago
Yes, I screwed up setting target milestone so it fell off my radar screen.  Sorry.
Target Milestone: --- → mozilla0.9.6
(Assignee)

Comment 13

17 years ago
Fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.