Interrupted http/ftp download if the subsequent 'Save As...' window is unanswered

RESOLVED DUPLICATE of bug 74331

Status

defect
RESOLVED DUPLICATE of bug 74331
17 years ago
3 years ago

People

(Reporter: harisri, Assigned: law)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: async save, URL)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
BuildID:    2002031008

I have a problem while using Mozilla to download (in http/ftp) files from the
net. It does not complete a download session if it is waiting for user response
on subsequent download(s) (for example, waiting for user response in 'Save
As...' window)



Reproducible: Always
Steps to Reproduce:
1.Type either http://www.de.kernel.org/pub/linux/kernel/v2.4/ or
ftp://ftp.us.kernel.org/pub/linux/kernel/v2.4/
2.Right click on linux-2.4.0.tar.gz and select 'Save Link As...'
3.Select 'Save'
4. Wait for couple seconds/minutes based on your speed of your connectivity for
the first download session to progress (for example, wait until it progress to 10%)
5. Now right click on patch-2.4.1.gz and select 'Save Link As...'
5. DO NOT RESPOND TO THE 'Save As' WINDOW, and let it just stay unanswered
6. Wait for 5 to 10 minutes (perhaps take a break for coffee, tea etc..)
7. Watch the progress window on the first download session (for the
'linux-2.4.0.tar.gz' download) stops
8.Irrespective of either choosing to 'Save' the file, or 'Cancel' on the second
download session window, you can notice that the first download session fails,
and does not complete the download.


Actual Results:  Mozilla does not download in http/ftp when it is waiting for
user response on subsequent windows.

Expected Results:  Mozilla should continue to download the first download
session, while waiting for the user response on second download session window.

I have found the same behaviour on 0.9.9 build and 23 March 2002 nightly build
on Windows NT 4.0/SP5 computer.

This is my first bug report for Mozilla, please do not flame me if it is a well
known bug or if I have explained it clearly. Please e-mail me for more information.

Thank you,
Hari.
-> file handling
Assignee: asa → law
Component: Browser-General → File Handling
QA Contact: doronr → sairuh
*** Bug 137909 has been marked as a duplicate of this bug. ***
confirm, os->all based on w98 dup
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
QA Contact: sairuh → petersen

Comment 4

16 years ago
This bug is still true on W2k+sp3 Build ID: 2003012508.
darin, would using that async copy stuff help here?  That should keep the
writing to file off the UI thread/event queue (which is blocked by the modal
dialog), right?
Whiteboard: async save

Comment 6

16 years ago
boris: i don't think that would help.. the problem is that necko delivers ODA
events to the event queue which was active when AsyncOpen was called.  the
second modal save as dialog pushes a new event queue, suspending the event queue
that necko is using.  the only necko-side solution would be to try to fanagle
things to always use the active event queue, but that has other ramifications. 
if necko were completely threadsafe then you could easily spawn a background
thread for saving, but that's not currently an option either.

*** This bug has been marked as a duplicate of 74331 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.