174136 - download dies when closing Mozilla via File/Exit but remains open when closing Mozilla via close button

Status: VERIFIED DUPLICATE of bug 28385

(SeaMonkey :: Download & File Handling, defect)

Description

[Az]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021012 Phoenix/0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021012 Phoenix/0.3

When i exit phoenix, any current downloads are ended.

I know u are going to say 'the downloads are managed by phoenix, if u dont want
to stop the download then dont close phoenix' but if u look at other browsers
(ie for sure) this does not happen.

Although the downloads are managed by the browser, they operate in a separate
window - i should be able to close the browser window without losing any downloads.

If i only want to donwload a file and not browse any pages, why should i have to
keep both windows open ? One of which is empty.

Reproducible: Always

Steps to Reproduce:
1. Download a file.
2. Begin download.
3. Close Browser

Actual Results:  
Browser closed and download stopped.

Expected Results:  
Closed browser and but continued download(s).

Comment 1

[David P James]

Confirm. Both Galeon and Konqueror (Linux) allow for continuation of downloads
after browser shut-down. Mozilla does as well (I think... Phoenix was running at
the same time).

Comment 2

[alanjstr]

What is the method for closing the browser that causes this to happen?  Sounds
kinda like Mozilla Bug 28385

Comment 3

[Simon Paquet [:sipaq]]

I don't see this on my 10/20/2002 build under W2k.
Reporter, can you download the current Nightly and see if the bug still occurs.

Comment 4

[Shawn Lindsay]

The download stays active after closing the browser.  However, if you try to
restart the browser while the download is in progress, the profile manager is
invoked, i.e. a dialog appears which asks you to choose a profile as if you're
using Phoenix for the first time. (I hit cancel, waited for the download to
finish and then restarted Phoenix which started without invoking the profile
manager.) 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021020 Phoenix/0.3,
build 2002102008

Comment 5

[Stephen Perry]

Can see this problem on Linux Phoenix 20021020 nightly - exactly the
same thing thing happens on Mozilla 1.2a as well so does indeed sound
like Mozilla Bug 28385 as mentioned earlier.

To see this bug you have to close the browser with the quit button -
if the last browser window is closed the download continues until the
download dialogue is dismissed at which point the browser exits.

Comment 6

[Ivan Brkanac]

wfm
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021021
Phoenix/0.3 win2k sp3
I opened download and the quited mozila, download continued. After that I
restatrted mozilla and it loaded OK no profile dialog.

Comment 7

[Kim]

wfm using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021020 Phoenix/0.3

I can confirm that this bug used to happen fairly consistantly to me, and drove
me crazy, but it went away after updating to a newer version. 

Comment 8

[Kim]

Okay, I reproduced it, I missed the part about how it was reproduced in a later
post there.

done using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021020
Phoenix/0.3

Steps to reproduce: 
1. Start a download with phoenix
2. Quit using "Exit"

it isn't specifically mentioned before, closing using the close button shows the
correct behavior. Missing things like this is why debugging at midnight is an
icky idea.

Comment 9

[Simon Paquet [:sipaq]]

Using the instructions given by Kim in comment 8, I could reproduce this bug
using the latest mozilla and phoenix builds (10/22/2002 and 10/23/2002) running
under W2k. 

I don't think that this is a dupe of bug 28385, which deals only with a warning
message before exiting Mozilla/Phoenix nor of bug 147254 which only deals with
Mozilla running in background issues due to turbo mode.

Therefore I'm changing Product (this is a Mozilla issue after all), Component,
Severity (this is a dataloss bug), OS (this is not Windows specific regarding to
comment 5) and Summary (to clarify things a little bit) entries.

Comment 10

[Max Alekseyev]

Related to (dup of?) bug 149848

Comment 11

[Daniel Wang]

*** This bug has been marked as a duplicate of 28385 ***

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

verified.