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)
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?
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 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 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
--> law, you gonna check this in?
Assignee: blakeross → law
Yes, I screwed up setting target milestone so it fell off my radar screen. Sorry.
Target Milestone: --- → mozilla0.9.6
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
You need to log in before you can comment on or make changes to this bug.