Closed
Bug 85603
Opened 24 years ago
Closed 23 years ago
download does not stop when the download window is closed
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 101182
People
(Reporter: shao, Assigned: law)
References
()
Details
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•24 years ago
|
||
For people on networks where they are charged for data transfer, that might actually be a problem.
Comment 2•24 years ago
|
||
WFM Linux 2001061306 Starts downloading to a file in /tmp; when I cancel, the file disappears. Weird.
Comment 3•24 years ago
|
||
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•24 years ago
|
||
Oh, you're right, I closed the window directly instead of via wm. Following the reporter's instructions, I can confirm this.
Assignee: asa → blakeross
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: GUI Features
Ever confirmed: true
QA Contact: doronr → sairuh
Comment 5•24 years ago
|
||
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...?
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?
url: N/A ? you're kidding. does this happen for all window managers? law meant bug 56162.
Assignee: blake → trudelle
Component: XP Apps: GUI Features → XP Toolkit/Widgets
QA Contact: sairuh → aegis
Comment 8•24 years ago
|
||
Sounds like a Doctor,Doctor bug. ->dr/future
Assignee: trudelle → dr
Target Milestone: --- → Future
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?
Status: NEW → ASSIGNED
Reporter | ||
Comment 10•24 years ago
|
||
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•23 years ago
|
||
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm
Comment 12•23 years ago
|
||
[spam] dr@netscape.com's bugs subject to redistribution by chofmann. R!
Assignee: dr → chofmann
Status: ASSIGNED → NEW
Priority: P3 → --
Target Milestone: Future → ---
Comment 13•23 years ago
|
||
over to file handling.
Assignee: chofmann → law
Component: XP Toolkit/Widgets → File Handling
QA Contact: jrgm → sairuh
Assignee | ||
Comment 14•23 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•