Closed Bug 147254 Opened 23 years ago Closed 15 years ago

Download dies when last window is closed

Categories

(SeaMonkey :: Download & File Handling, defect)

Product:
SeaMonkey
Component:
Download & File Handling
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 28385

People

(Reporter: psychocybershark, Unassigned)

References

Details

(Keywords: dataloss)

Attachments

(1 file)

This is the error in the Manager I am describing
39.73 KB, image/png
Details 
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Um... no.  This is at best dependent. or am I totally missing something?
Status: RESOLVED → REOPENED
Depends on: 146340
Resolution: DUPLICATE → ---
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.
Assignee: law → blaker
Status: REOPENED → NEW
Component: QuickLaunch (AKA turbo mode) → Download Manager
Keywords: dataloss
QA Contact: gbush → sairuh
Summary: Download Manager dies when closed. → Download dies when last window is closed
*** 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.
QA Contact: sairuh → petersen
*** 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. ***
Depends on: progressquit
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.
Severity: normal → major
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.
Severity: major → critical
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. ***
Flags: blocking1.4a?
Flags: blocking1.4a? → blocking1.4a-
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.
Product: Browser → Seamonkey
Assignee: bross2 → download-manager
QA Contact: chrispetersen
Assignee: download-manager → nobody
QA Contact: download-manager
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
Status: NEW → UNCONFIRMED
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: