Last Comment Bug 102277 - "Saving File" keep-open checkbox shouldn't work with helper-apps
: "Saving File" keep-open checkbox shouldn't work with helper-apps
Status: NEW
Product: Firefox
Classification: Client Software
Component: File Handling (show other bugs)
: unspecified
: All All
-- enhancement with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: :Paolo Amadini
: 116988 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2001-09-28 15:55 PDT by Eric Seppanen
Modified: 2016-06-22 11:26 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Eric Seppanen 2001-09-28 15:55:28 PDT
The "Saving File" window has a checkbox that says "Keep this window open after
the download is complete".  Presumably, this was meant as a helpful reminder so
you don't forget about something you left downloading.  However, this feature
becomes a pain because the check-box is persistent; checking it once affects all
future dialogs (until you un-check it).  Still no problem until you realize it
affects file downloads that are to be run by helper-apps.  So even though I like
the "keep-open" feature, I don't use it because it's too much of a pain in the
ass dismissing the windows that get left open for every MP3 file I play from
Mozilla.  This is with 0.9.4.  Not sure if this is a bug or enhancement, but
possible solutions include:
1. Make the check-box default to off, and make it non-persistent.  Every time a
user wants the window to hang around as a reminder, they have to check the box
during the download.
2. (preferred) Bypass the "keep-open" setting when the download is going to
launch a helper app.
Comment 1 User image Niels Aufbau 2001-09-29 22:03:38 PDT
I can confirm that this happens with 2001092803 on Windows 98.  I encounter this
bug quite often, because I use Mozilla to watch porn videos and also to download
new nightlies.

I think this should be in the "XP Apps: GUI Features" component, since several
other bugs involving this dialog and the "keep this window" checkbox are in that

Steps to reproduce:
1. Start downloading a new nightly build.
2. Check "keep this window open after the download is complete".
3. Wait for the download to finish.  (This might not be necessary).
4. Go to
5. Click on of the "Movie" links in the middle of the page.
6. Choose "open using realplayer" (this should be the default).

Actual result: end up with a useless download window and a real player window

Expected result: download window should go away when download finishes, leaving
only a real player window

The funny thing is, I've gotten into the habit of anticipating and getting ready
to kill these download windows the same way I used to with pop-up windows. 
These windows are most certainly not as annoying as pop-up advertisements, of
course (Mozilla is tolerable as a porn browser now that the pop-up killing pref
Comment 2 User image Asa Dotzler [:asa] 2001-10-01 23:28:03 PDT
->XP Apps
Comment 3 User image sairuh (rarely reading bugmail) 2001-10-09 15:07:54 PDT
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 4 User image Peter Trudelle 2001-11-27 17:14:28 PST
->law (enjoy! ;-)
Comment 5 User image Bill Law 2001-11-29 10:48:30 PST
I think the right thing to do is have the checkbox unchecked whenever 
downloading a file to open with a helper app.  I don't see any harm in leaving 
the checkbox there in such cases, in case the user wants to leave the dialog 
open (to save the file, as a reminder, whatever).

This will be easy to fix at the same time as the bug about changing the dialog 
title and save-to location info in the case where we're opening with a helper 
Comment 6 User image Hakon 2002-02-01 06:26:03 PST
*** Bug 116988 has been marked as a duplicate of this bug. ***
Comment 7 User image Bill Law 2002-02-06 13:02:19 PST
Spam: Setting target milestone for all these to Future.

Please note that most, if not all, will be fixed in the course of the work I'm 
doing for bug 27609.  That fact is noted in the "depends on" field for each of 
these bugs (I think; go ahead and remedy that if you like).

I just don't have time to deal with the wrath that comes with having too many 

Note You need to log in before you can comment on or make changes to this bug.