Last Comment Bug 28385 - Alert user before file->exit if files are still downloading
: Alert user before file->exit if files are still downloading
Status: RESOLVED WONTFIX
[adt3] [UI]
: dataloss, relnote
Product: SeaMonkey
Classification: Client Software
Component: Download & File Handling (show other bugs)
: Trunk
: All All
: -- normal with 47 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 95416 104469 147254 155980 159679 163954 174136 183757 194219 195863 208411 225153 228581 251884 315145 (view as bug list)
Depends on: 238391
Blocks: 78106 127253 163954
  Show dependency treegraph
 
Reported: 2000-02-18 09:29 PST by gabriel
Modified: 2014-04-26 02:21 PDT (History)
67 users (show)
chofmann: blocking1.7b-
asa: blocking1.7-
iann_bugzilla: blocking‑seamonkey2.0-
iann_bugzilla: blocking‑seamonkey2.0a1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description gabriel 2000-02-18 09:29:42 PST
Many times when using Netscape, I exit from the application, only to realise I
was still halfway thru downloading (save to disk) a file. This is extremely
infuriating. It would be wonderful if Mozilla warned the user 'You are still
downloading files, do you really want to quit ?' before exiting. Apologies if
this is a dup.
Comment 1 Christine Begle 2000-02-18 09:57:49 PST
maybe a networking thing?  
Comment 2 Daniel Bratell 2000-02-18 09:58:31 PST
That's a cool idea. Right now, Mozilla keeps the download alive if you close the 
last window but quits the download if you choose quit from the file menu in a 
Mozilla window. It really should ask for permission to quit the download since 
they're probably not meant to be cancelled
Comment 3 Christine Begle 2000-02-21 13:30:30 PST
udpating component owner.
Comment 4 Warren Harris 2000-02-21 23:40:25 PST
=> law
Comment 5 Jesse Ruderman 2000-11-19 01:47:50 PST
May depend on bug 44602.
Comment 6 Bill Law 2000-12-28 19:56:38 PST
Another file download nomination.  Problem is a PITA, need to see how hard it is
to come up with some acceptable fix.
Comment 7 Viswanath Ramachandran 2001-04-20 00:30:57 PDT
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Comment 8 Viswanath Ramachandran 2001-05-29 17:37:15 PDT
nav triage: moving to m0.9.3. 
Comment 9 Blake Ross 2001-06-19 15:07:41 PDT
Matthew: proper UI/wording?  Should download windows just not be closed upon 
quitting?
Comment 10 Blake Ross 2001-06-20 13:42:27 PDT
--> me
Comment 11 Matthew Paul Thomas 2001-07-08 08:20:32 PDT
> Matthew: proper UI/wording?

If you want to truly delight people:
+------------------------------------------------------+
|::::::::::::::::::::::::::::::::::::::::::::::::::::::|
+------------------------------------------------------+
|   .   If you quit now, 3 files which are being       | \ large
|  /!\  downloaded will not download completely. Are   | } system
|  """  you sure you want to quit?                     | / font
|                                                      |
|       Downloading will finish in about 17 minutes.   | } small system font
|                                                      |
|                         ( Cancel ) (( Quit Anyway )) |
+------------------------------------------------------+

Show this alert *before* any windows are closed -- if the user is resigned to 
spending another 17 minutes online, she may wish to continue browsing or 
whatever in her existing windows. And use separate strings on Windows, with 
`exit' in the place of `quit'.

> Should download windows just not be closed upon quitting?

Yes -- but that requires making the browser and the download manager separate 
executables. Otherwise you're not telling the truth about what `Quit'/`Exit' 
means, and not telling the truth is marginally worse than putting up an extra 
alert.

See also bug 65121 (though that bug doesn't apply to Mac OS, so it wouldn't 
make this bug obsolete).
Comment 12 Peter Trudelle 2001-09-16 17:31:48 PDT
dataloss, critical severity
Comment 13 Blake Ross 2001-09-18 15:28:41 PDT
--> ben, he's doing download mgr stuff (or thinking about it)
Comment 14 Ben Goodger (use ben at mozilla dot org for email) 2001-10-03 00:20:06 PDT
Could be part of download manager, but .1 because not immediately required. 
Comment 15 sairuh (rarely reading bugmail) 2001-10-09 15:04:06 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 16 Jesse Ruderman 2001-10-12 15:49:24 PDT
*** Bug 104469 has been marked as a duplicate of this bug. ***
Comment 17 Peter Trudelle 2002-03-12 20:31:04 PST
So what happened with this, is is a part of download manager?
Comment 18 Peter Trudelle 2002-03-19 14:21:00 PST
nsbeta1+ per Nav triage team, nav3, ->1.0
Comment 19 selmer (gone) 2002-04-03 14:03:15 PST
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!
Comment 20 Peter Trudelle 2002-04-09 22:55:30 PDT
converting nav3->adt3
Comment 21 Ben Goodger (use ben at mozilla dot org for email) 2002-04-16 16:45:47 PDT
-> blake
Comment 22 Blake Ross 2002-04-16 17:17:42 PDT
This really isn't specific to download manager either.  --> law (I know you have
a lot on your plate, but so do I. Maybe I can get to this soon.)
Comment 23 Bill Law 2002-04-16 17:48:18 PDT
I happened to think about this again recently while working on something related.

Here's an idea: if we just add a function named tryToClose to the download
progress <window> (and in the download manager window?), then this will be
called at File->Quit time.  There, we can put up a dialog like the one mpt
suggests and cancel the quit if the user says to.

This might be complicated by download manager interactions (no progress dialogs,
download manager not open) but otherwise might provide a means to a simple fix.
 I won't get to it soon since I have [adt2] and [adt1] stuff.
Comment 24 Peter Trudelle 2002-04-17 17:34:52 PDT
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.
Comment 25 scottputterman 2002-04-22 19:32:49 PDT
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Comment 26 scottputterman 2002-04-22 19:57:59 PDT
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Comment 27 Nahor 2002-05-08 15:29:22 PDT
This needs to be fixed quickly especially since the download manager is the
default. With the progress dialog, one can see them before quitting. But now,
the downloads are hidden and the download manager can be discarded at will. So
how does one know he can "safely" quit? First, he has to go in "Tools | Download
Manager" (no shortcut). Then he can go in "File | Quit". That's not what I would
call "user friendly"!!!!
I understand that there is still some important work to do for the final release
but for this, people are going to complain (actually, we already do :p) and even
more now that the download are not readily visible in the taskbar (or equivalent)

Because of bug 142310, I couldn't try but what will happen if one close the
download manager window then close the last navigator window?
Comment 28 Andrew Hagen 2002-05-11 08:08:50 PDT
Proposed relnote: If the user is downloading a file in the background with
Mozilla, and the user exits Mozilla from the File menu, the download will abort
without warning. 
Comment 29 Jesse Ruderman 2002-07-02 11:51:18 PDT
See also bug 147254, Download dies when last window is closed.  Changing summary
to differentiate from 147254.
Comment 30 R.K.Aa. 2002-07-05 19:45:21 PDT
*** Bug 155980 has been marked as a duplicate of this bug. ***
Comment 31 sairuh (rarely reading bugmail) 2002-07-30 13:17:25 PDT
would it be possible to fix this for buffy?

this also affects embedded apps, such as chimera.
Comment 32 Samir Gehani 2002-08-02 11:35:39 PDT
Nav traige team: nsbeta1+/adt3
Comment 33 Daniel Wang 2002-08-27 20:18:36 PDT
*** Bug 159679 has been marked as a duplicate of this bug. ***
Comment 34 Andrei Boros 2002-09-25 00:47:21 PDT
While I agree with the suggestion in comment #11 (I would have made a similar
one myself if it wasn't there), I must add that the confirmation dialog should
appear at all times, even if there are no downloads in progress.

A possible exception (but not really necessary), it is not required if _ONLY
ONE_ mozilla window is displayed.
Comment 35 johann.petrak@gmail.com 2002-09-25 02:31:00 PDT
re comment #34: no - confirmation should only be asked for if there is the 
danger of data loss. This bug is about a confirmation when downloads
are going on. Your suggestion does not belong in this bug, but 
bug 39057 (verified wontfix).
Comment 36 gabriel 2002-09-25 05:17:01 PDT
This bug has been open for 2.5 years. Is any progress being made on it ?
Comment 37 Bernard Alleysson 2002-09-30 15:16:03 PDT
This is related to bug 131500, which could be formulated as:
"Alert user before file->work offline if files are still downloading"
Comment 38 Matthias Versen [:Matti] 2002-12-05 10:08:45 PST
*** Bug 183757 has been marked as a duplicate of this bug. ***
Comment 39 Samir Gehani 2002-12-17 17:52:35 PST
Over to Jan.
Comment 40 Daniel Wang 2003-03-05 13:03:23 PST
*** Bug 174136 has been marked as a duplicate of this bug. ***
Comment 41 Daniel Wang 2003-03-05 13:27:56 PST
*** Bug 195863 has been marked as a duplicate of this bug. ***
Comment 42 tyl2 2003-03-13 14:07:55 PST
About Comment #35, I'm sure we've all have downloaded files from low-bandwidth
servers that are very hard to restart downloads from. It's arguably a form of
data loss when data on your HD is rendered useless, as a partial doanload is. At
least let users choose whether to have the warning.
Comment 43 Andrew Hagen 2003-04-26 12:30:55 PDT
*** Bug 95416 has been marked as a duplicate of this bug. ***
Comment 44 Andrew Hagen 2003-04-26 12:34:52 PDT
*** Bug 194219 has been marked as a duplicate of this bug. ***
Comment 45 Christian :Biesinger (don't email me, ping me on IRC) 2003-04-26 12:38:58 PDT
from Bug 194219 :
------- Additional Comment #5 From Christian Biesinger  2003-04-19 15:24 -------

http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/globalOverlay.js#9

isn't it lovely, there is currently no way to fix this bug...


(but I may of course be missing something...)
Comment 46 Simon Fraser 2003-04-28 09:30:26 PDT
Sure there is. Implement 'tryToClose' on those windows that handle downloads.
Comment 47 Gili 2003-05-03 13:17:58 PDT
Hey guys, this bug is 3 years old, blocks 3 other bugs and has 38 people waiting
on it.

Why don't you fix it already?
Comment 48 Christian :Biesinger (don't email me, ping me on IRC) 2003-05-04 11:47:07 PDT
smfr: such windows don't necessarily exist, afaik, as you need not have progress
windows and can have the dl mgr window closed
Comment 49 James Salsman 2003-05-14 16:52:41 PDT
Why don't downloads fork to a helper app?  Is it too much to maintain a bunch 
of lightweight, one-function download windows?

As for downloads that don't have their own windows, I suggest WONTFIX because 
people generally want network activity to halt when they close its associated 
window.

Comment 50 James Salsman 2003-05-14 17:04:12 PDT
Added dependency to the bug which requires computation of download status.

Ccing Bill Law (desktop integration and file download) from XP-Apps
Comment 51 Gili 2003-05-14 23:00:18 PDT
Let me suggest one possible solution: as long as mozturbo is running, downloads
should continue downloading. This is similar to Kazaa where downloads continue
as long as application is alive in the launch bar (bottom right in Windows).
Comment 52 Dave Warren 2003-05-15 01:14:56 PDT
RE #51... It's a good thought, but unfortunately turbo mode is broken, Mozilla
exits completely and restarts, until this behaviour gets corrected it won't be
possible.
Comment 53 johann.petrak@gmail.com 2003-05-15 02:46:51 PDT
re #51: turbo only exists or makes sense for the windows port, and this is a
problem on all OS.
Comment 54 José Jeria 2003-06-05 08:31:29 PDT
*** Bug 208411 has been marked as a duplicate of this bug. ***
Comment 55 Caspy7 2003-06-24 22:22:03 PDT
Ok, I suppose I need some clarification here.

I've read through the bug and it sounds like all that is necessary is that we
are able to query whether there there are one or more downloads currently in
progress.  If there are, then present something to the effect of the dialog
proposed in comment 11.  Is that right?

So why, then, is this dependent on bug 36776 (Show download progress in window
icon)?  That bug is caught up in colors and behaviors of icons.  All we really
need to know is, "are there any downloads in progress? Yes or no?"

Is there a neccesity to create a means to do this in a seperate bug?

Might I suggest that if there is a desire do deal with this problem in a more
complex way other than a simple warning dialog that a seperate bug be filed or
this bug will likely take another 3 years to be resolved.
Comment 56 Paul Dufresne 2003-06-30 21:42:39 PDT
I was to report as a bug, that when I restart Mozilla,
the download manager have cancelled my download,
rather than continue downloading where it was. Which
is what I expect it to do. But somehow, it seems way
much more complex than can be implemented for now.
I almost what to go see the code and see what should
be done for doing this. Afterall, this is supported
both by FTP and HTTP (1.1?) for quite a long time.
Comment 57 Paul Dufresne 2003-07-01 01:51:18 PDT
Well, actually, I guess it is best to simply pause all downloading files
before quiting Mozilla. That way, one have full bandwith when he restart
Mozilla, and still can resume download (which is impossible now because
they are cancelled).

Comment #11 is still usefull for dowloading files which are not restartable,
because the server don't support it. But for now, nothing shows that Mozilla
try to know a download is restartable. So for now, what seems to make sense
is just to pause all files before quitting.
Comment 58 Thomas Brown 2003-08-16 19:00:08 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030815

Isn't this bug moot at this point, as Mozilla now exhibits the default behavior
of Netscape 4.x where downloads will continue to run and will complete
successfully even after the last browser window is closed (or until the user
cancels the download)?
Comment 59 Jesse Ruderman 2003-09-29 22:02:42 PDT
See also bug 219758, same bug for Firebird.
Comment 60 Martyr 2003-11-01 21:43:34 PST
Not moot. Still occurs in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.5) Gecko/20030925.
Comment 61 Alfonso Martinez 2003-11-09 14:54:21 PST
*** Bug 225153 has been marked as a duplicate of this bug. ***
Comment 62 José Jeria 2003-12-15 12:58:12 PST
*** Bug 228581 has been marked as a duplicate of this bug. ***
Comment 63 Gili 2004-02-19 15:50:48 PST
Update to the person in charge of this issue:

- 52 users waiting for a fix
- Issue is 4 years old
Comment 64 Martyr 2004-02-19 16:04:49 PST
I agree. This is a cryin' shame. What is getting in the way of development? It
seems to me that the TryToClose () routine is a fine solution. The UI is also
already sketched out. Is there some big ugly problem in the code? Could we just
mark it as blocking a release to get some attention? This thing has been moved
to future releases a ton of times. 
 
Comment 65 chris hofmann 2004-03-02 12:38:52 PST
for anyone that wants/needs this they should migrate to firefox... 

from ben:
exit the app, we prompt first and ask if you want to cancel (#) downloads.
once we get cross session resume this won't be necessary. 

unless jan varga or someone has cycles to to this in the full suite it's
unlikely  to appear there...  guess we should mark this works for me in firefox,
or won't fix in seamonkey unless we can get someone to step up.
Comment 66 chris hofmann 2004-03-02 12:39:38 PST
for anyone that wants/needs this they should migrate to firefox... 

from ben:
exit the app, we prompt first and ask if you want to cancel (#) downloads.
once we get cross session resume this won't be necessary. 

unless jan varga or someone has cycles to to this in the full suite it's
unlikely  to appear there...  guess we should mark this works for me in firefox,
or won't fix in seamonkey unless we can get someone to step up.
Comment 67 johann.petrak@gmail.com 2004-03-02 16:13:20 PST
please do not abuse bugzilla as a firefox promotion forum. There are many people
who have reasons why to prefer the suite and want it fixed it the suite. If
somebody comes up with a patch it will get fixed - there is not reason to
WONTFIX this. 
Comment 68 Frédéric Buclin 2004-03-03 01:16:25 PST
I totally agree with Johann Petrak. This bug seems important enough to be
considered in the suite as well! 38 votes are here to confirm our opinion!!!

If you do not want to fix such a bug in the suite, then stop releasing Mozilla
Suite, things would be clearer and effort concentrated on one product!

I sincerly hoped this bug to be fixed in 1.7... :-(
Comment 69 chris hofmann 2004-03-17 08:24:05 PST
the intent was not to promote firefox. the intent was just to a clearity about
where solutions to this problem can be found. if someone comes up with a good
patch for this to apply to the suite we would definitely take it.  
Comment 70 Frédéric Buclin 2004-03-19 03:02:21 PST
I know nothing about C or C++ programmation but what could prevent Mozilla to
check how many downloads are in progress and ask the user to confirm to quit if
this number is non zero?

If I understand (more or less) correctly, canQuitApplication() checks if Mozilla
can quit and is called by goQuitApplication() in
http://lxr.mozilla.org/mozilla/source/toolkit/content/globalOverlay.js#24

Moreover, numActiveDownloads seems to count how many downloads are in progress
in
http://lxr.mozilla.org/seamonkey/source/embedding/browser/powerplant/source/UDownloadDisplay.cpp#192

Could not canQuitApplication() check if numActiveDownloads == 0 ?

Please don't laugh, as I said: I know nothing about C++! I am just surprised
that this bug remains open for such a long time (4 years now).
Comment 71 Asa Dotzler [:asa] 2004-03-19 12:14:58 PST
not going to block the release on a feature that would require significant
changes to localizable strings. We're past under L10N freeze. 
Comment 72 timeless 2004-03-22 23:08:17 PST
LpSolit@netscape.net: in short, you're off by a module.
powerplant is a mac embedding system, it's not close to the download manager in 
question (which lives in 
<http://lxr.mozilla.org/source/xpfe/components/download-manager/src/nsDownloadMa
nager.cpp>).

chofmann: your comments were not constructive. if you want to provide clarity, 
provide an lxr url 
<http://lxr.mozilla.org/mozilla/source/toolkit/components/downloads/src/nsDownlo
adManager.cpp> or a keyword/search string.

for people playing along at home, the magic words are observer service and 
topics "quit-application" and "quit-application-requested". The last important 
piece is: 
http://lxr.mozilla.org/mozilla/source/toolkit/content/globalOverlay.js#30 which 
solves 
http://lxr.mozilla.org/mozilla/source/xpfe/global/resources/content/globalOverla
y.js#9
Comment 73 Christian :Biesinger (don't email me, ping me on IRC) 2004-03-23 14:54:18 PST
fixing this requires bug 238391 to be fixed

bug 36776 seems unrelated, removing from dependency field.
Comment 74 R.K.Aa. 2004-07-17 08:30:27 PDT
*** Bug 251884 has been marked as a duplicate of this bug. ***
Comment 75 Bruno 'Aqualon' Escherl 2005-11-05 17:46:20 PST
*** Bug 315145 has been marked as a duplicate of this bug. ***
Comment 76 Randy Santmann 2006-12-27 14:04:56 PST
*** Bug 163954 has been marked as a duplicate of this bug. ***
Comment 77 Randy Santmann 2007-08-10 08:15:27 PDT
This bug has been resolved (at least in Mozilla).  It now prompts before exiting.  Shouldn't someone close this thread?
Comment 78 Andrew Jans 2007-09-04 10:18:13 PDT
(In reply to comment #77)
> This bug has been resolved (at least in Mozilla).  It now prompts before
> exiting.  Shouldn't someone close this thread?

The prompting is great, but it would be really nice to have the following options:

<current prompt text>

[Yes - Shutdown everything] [No - Show Download Manager, Close Browser] [Cancel - Leave Browser Open]

Thanks for considering this.
Comment 79 nick geil 2007-09-25 14:04:38 PDT
Indeed it has already been resolved.  This thread will be closed when someone who can sees it.
Comment 80 Bruno 'Aqualon' Escherl 2007-09-25 14:31:45 PDT
It's resolved in Firefox but not in SeaMonkey, does somebody know what Firefox bug fixed it?
Comment 81 AndrewM 2007-10-14 10:32:58 PDT
The bug that was fixed in Firefox was 219758, so I think Product should be changed to Mozilla Application Suite.
Comment 82 Damian Yerrick 2007-10-16 14:18:14 PDT
Before I close this, which patch FIXED this in SeaMonkey?  Or should I
just WFM it as having been FIXED elsewhere?
Comment 83 AndrewM 2007-10-16 14:57:32 PDT
(In reply to comment #82)
> Before I close this, which patch FIXED this in SeaMonkey?  Or should I
> just WFM it as having been FIXED elsewhere?

I didn't know it was fixed in SeaMonkey, I was just saying that someone should do what you have just done (change the Product to Mozilla Application Suite) :-)
Comment 84 Ian Neal 2008-08-16 14:25:46 PDT
As far as I can see this is not fixed on SeaMonkey trunk though that will probably change when we switch to toolkit's download manager (as I think that has this protection built in) - Callek will need to advise on it.
Comment 85 Ian Neal 2008-08-26 05:33:13 PDT
Pushing out to 2.0.
Comment 86 Robert Kaiser (not working on stability any more) 2009-08-06 15:17:18 PDT
Firefox is not doing this any more, presumably because the current download manager implementation can resume downloads after restarting.
Also because of the same, I don't think we need to do this for SeaMonkey with this implementation, so marking WONTFIX.
Comment 87 Robert Kaiser (not working on stability any more) 2009-08-06 15:31:47 PDT
*** Bug 147254 has been marked as a duplicate of this bug. ***
Comment 88 johann.petrak@gmail.com 2009-08-06 17:10:59 PDT
Is it not the case, that the resume feature can only work with servers that support to resume a download? Also, even if a download can be resumed, a user might not be aware that it is still going on and a warning would be extremely useful.
Firefox warns and nags in all kinds of situations (e.g. when more than one tab is being closed by default) that are much less useful, it is hard to understand why it should not warn in this case.
Comment 89 Graham Leggett 2009-08-06 18:02:34 PDT
The assumption that all webservers are able to support resume is invalid. Many downloads rely on the existence of sessions (wiped on FF exit), or are served by application servers that don't support HTTP ranges.
Comment 90 Ian Neal 2009-08-27 14:02:06 PDT
Not blocking 2.0 on this

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