On 2002052508 and probably all recent trunk builds, likely as a result of the Quick Launch's closing and reopening behaviour, when you are downloading, then close all windows, the download dies. Come back in to Download Manager, and you will see an error in that download. Normally, if you were to close all windows the download would continue going, but this bug kills it.

So.. you close all windows. This exits Mozilla, right? Why should the download continue?

It's a strange error; the bar is still there yet nothing works, so you must delete. I have Quick Launch on, so closing all windows would normally leave the download going in the background.

Maybe you don't know what I'm referring to by "Quick Launch's closing and reopening behaviour"...I'm sure a bug is filed--upon which many are dependant--about this already: <http://www.mozillazine.org/talkback/read.php?f=2&i=1511&t=1511>

Found it: Bug 146340.

Marking dupe of bug 146340 as per reporter comments. *** This bug has been marked as a duplicate of 146340 ***

Um... no. This is at best dependent. or am I totally missing something?

Boris, you are not missing anything. You got what I meant right on, although maybe I wasn't clear. Comment 4 was an ammendment to Comment 3.

I don't get it, if you close all windows, you've closed the DL Mgr too. We should not have any 'invisible' downloading. Would you please write clear, complete steps to reproduce this defect?

Peter, this is a side effect of the fix for Bug 98673. In branch builds for example, with the old -turbo model, after all windows are closed, Mozilla is still running in the background as seen on the tray. All downloads are still occuring as well. Expected Results (seen in 1.0 branch w/Download Manager & Quick Launch being used): 1) Click to Download something 2) Close all windows, but leave Mozilla on in background 3) Open Download Manager, and download is still in progress/can be manipulated Actual Results (in trunk builds with -turbo...Download Manager on by default): 1) Click to Download something 2) Close all windows, but leave Mozilla on in background 3) Open Download Manager when -turbo tray icon returns 4) Note that download has ceased, can't be resumed, and has a blank status bar In other words, we need a way to leave Download Manager on in the background if it's in use when someone closes all windows, otherwise you can't download anything if you exit the browser; if this is a real download manager, it must be usable even if it's window has been closed.

Closing the download manager when Quick Launch is enabled should not kill the downloads. One way to fix that would be to use old-style quicklaunch until the downloads are complete. (Treat a background download the same way you treat an open window.) I'm not sure what closing Download Manager should do with Quick Launch disabled. It could have a dialog asking "do you want to stop the current downloads?"

Whatever download manager does with quicklaunch disabled, it should also do with quicklaunch enabled. The presence of quicklaunch should be completely invisible to the user -- all behavior should be the same in the two cases except that the restart time should be quicker.

I see what you're saying Stephen, however, I think of this: when a download is in progress, if the Manager window is closed by the user, the download continues, and no error occurs when the window is reopened, as long as another window, such as the Navigator window, is open throughout that time. However, if the Manager is the last window open and is closed, the download fails, and opon looking at the Manager in a subsequent use, that download shows with a blank status bar which isn't supposed to be there. Anyway, I propose that, at least in Quick Launch, this this inconsistent behaviour not be allowed. We've gotten a bit off-topic here though. The original problem is that when downloading and the Manager window is closed, as well as all other windows, when the Manager is reopened there is some kind of error in the download, and it doesn't show a 'Cancelled' status or something similar.

Morse is right, quick launch should not affect the behavior of download manager. How about making the download manager minimize-to-systray on close (like AIM does) whenever downloads are in progress? Mozilla would then not exit (or restart quicklaunch) until the downloads are complete. The "when starting a download, don't open anything" pref might become "open download manager but minimized". -> Download Manager.

*** Bug 155379 has been marked as a duplicate of this bug. ***

isn't this a bug 28385 dupl?

No, it deals directly with issues brought forth by bug 146340 and a possible remedy, and directly with the error in the status of the interrupted download in the Manager.

Look at the second-last download. Not only does it look like that, but it also cannot be manipulated through normal commands; it can only be shown in explorer (or at least the destination directory is shown) and removed from the list. Really, though, if you are interested, don't take my word for it, look at it yourself! This may have been around long before, but on 2002072704 (trunk), after this error occurs, you cannot reopen the Manager unless you download something else.

*** Bug 157421 has been marked as a duplicate of this bug. ***

*** Bug 182841 has been marked as a duplicate of this bug. ***

This bug is really annoying, and it hast been in Mozilla only since 1.2 final (had no problems with 1.2a). I do NOT use the download manager, just the good old download window, and as soon as I close the last browser window, the download will fail, although the download window is still open and continues to download

This is quite annoying (I've had several >100MB downloads break because of this). It's even more annoying since the download manager doesn't have "resume" or even "restart" functionality.

*** Bug 184879 has been marked as a duplicate of this bug. ***

dupe of bug 95416??

No. Different dialog.

*** Bug 187140 has been marked as a duplicate of this bug. ***

*** Bug 187269 has been marked as a duplicate of this bug. ***

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20021229 Similar behavior (file downloaded but then deleted) in this case: 1. View a file via authenticated FTP: ftp://username@host.com/dir1/dir2/NO%20PARKING.jpg 2. The file shows up in a browser window. Right-click it and us "Save image as...". You will again be prompted for the FTP password and the file will be downloaded, but won't be saved.

Dataloss is never normal priority. Increasing.

Is Quick Launch necessary for this bug? If not: WFM with build 2003011008 under Win NT4 (with DL Manager or progress dialog). IMHO most of the dupes here are wrong (especially without Quick Launch) because they are more dupes of bug 181374 (progress dialog, download completes, file is missing instead of download dies), which is now fixed and WFM too.

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

Should download manager really behave the same regardless of whether Quick Launch is enabled? Some comments here indicate that people expect downloads to proceed in the background when Quick Launch is enabled. I filed bug 194219 which describes what I think should happen when exiting all browser windows with Quick Launch disabled. Maybe the behaviour described in bug 194219 should also apply when Quick Launch is enabled - i.e., cancel all downloads but prompt first? An even nicer fix would be the one suggested in comment 12 but thats a lot more work.

*** Bug 195371 has been marked as a duplicate of this bug. ***

How is this bug different from bug 28385? Comment 16 does not specify how the two bugs are different. Plan to dup.

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)?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 WFM with standard download dialog as well as with download manager. Tested with quick launch active (both single and multiple profiles).

Thomas, this bug is about closing ALL windows (including the download manager or progress dialog), not just the browser windows. It used to be that if quicklaunch was on and you closed all windows downloads would not stop; now they do.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614