Closed
Bug 95572
Opened 23 years ago
Closed 23 years ago
[RFE] Pressing "Launch File" or "Reveal Location" should close the "Saving File" window
Categories
(Core Graveyard :: File Handling, enhancement)
Core Graveyard
File Handling
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.6
People
(Reporter: luolong, Assigned: law)
References
Details
Attachments
(2 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
law
:
review+
mscott
:
superreview+
|
Details | Diff | Splinter Review |
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.
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.
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•23 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
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
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 ;)
Updated•23 years ago
|
Blocks: 78106
Keywords: mozilla0.9.6
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•23 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+
Comment 10•23 years ago
|
||
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
Assignee | ||
Comment 12•23 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•23 years ago
|
||
Fixed
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 14•23 years ago
|
||
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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•