85603 - download does not stop when the download window is closed

Status: VERIFIED DUPLICATE of bug 101182

(Core Graveyard :: File Handling, defect)

Description

[Shao Zhang]

Go to mozillazine.org, and download a nightly.

After the downloading started, close the download window by using the window
manager(i.e. not pressing any button in the download dialog window). The
dowloading still continues and there is no way to terminate it except using kill -9.

Produced on both linux and freebsd with fvwm 2.3.29 using the nightly 2001061309.

Comment 1

[Emlyn Shannon]

For people on networks where they are charged for data transfer, that might
actually be a problem.

Comment 2

[Chase Tingley]

WFM Linux 2001061306
Starts downloading to a file in /tmp; when I cancel, the file disappears. 
Weird.

Comment 3

[Stefan Seifert]

did you cancel download or close the window by window manager as the reporter said?

I think this may be a problem too for peoble on dial ups that have already so
little bandwith

Comment 4

[Chase Tingley]

Oh, you're right, I closed the window directly instead of via wm.

Following the reporter's instructions, I can confirm this.  

Comment 5

[sairuh (rarely reading bugmail)]

mscott/bill, is this expected behavior? don't think it would be, but i want to
double-check, wrt how downloading is handled, network-wise. perhaps this should
go over to networking...?

Comment 6

[Bill Law]

Sounds like a window/widget problem.  This dialog cancels the download when it
closes.  Does closing the window via the window manager bypass that?

I seem to recall another bug about that...let me go search...

...all I can find is bug 565162 (but there might be another one out there).

Basically, I need to know if the dialog's onunload handler is being called or
not.  Can a Linux developer tweak the .js and verify that for me, please?

Comment 7

[timeless]

url: N/A ? you're kidding.

does this happen for all window managers?  law meant bug 56162.

Comment 8

[Peter Trudelle]

Sounds like a Doctor,Doctor bug.  ->dr/future

Comment 9

[Dan Rosen]

Without looking at the code, it seems like this would be a question of hooking
the dialog's close handler to the same "cancel download" code as the cancel
button is currently hooked up to... That'd be my first guess, that it's just an
oversight. OTOH, if the reporter is *destroying* the window, that could be an
issue. We already have a bug pertaining to ill behavior when windows are
destroyed rather than properly closed: bug 56162.

Shao Zhang: Are you using the window manager's "destroy," or just using the
regular "close" button?

Comment 10

[Shao Zhang]

I am using the Windows Manager's Close command. The mozilla download window does
not have a close button, but for most window managers available in linux, you
can always bind a Close action to a key and execute it. This won't affect the
windows users too much.

By Close, I mean: 
              If  the window accepts the delete window protocol a
              message is sent to the window asking it  to  grace-
              fully remove itself.  If the window does not under-
              stand the delete window protocol then the window is
              destroyed  as  with  the Destroy command.  Note: if
              the window accepts the delete window  protocol  but
              does  not  close  itself in response, the window is
              not deleted.

Destroy will cause the entire mozilla to exit. This really sounds an easy fix to
me. Basically the code that hooked with the Cancel button is fine. So all we
need is to installed the same call back when the Close action is executed.

Comment 11

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 12

[Dan Rosen]

[spam] [e-mail]'s bugs subject to redistribution by chofmann. R!

Comment 13

[sairuh (rarely reading bugmail)]

over to file handling.

Comment 14

[Bill Law]

I know, this bug was opened first, but I've been working on that other one...

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

Comment 15

[sairuh (rarely reading bugmail)]

v