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

Status: RESOLVED DUPLICATE of bug 74331

(Core Graveyard :: File Handling, defect)

Description

[Srihari Vijayaraghavan]

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.

Comment 1

[Bradley Baetz (:bbaetz)]

-> file handling

Comment 2

[Tuukka Tolvanen (sp3000)]

*** Bug 137909 has been marked as a duplicate of this bug. ***

Comment 3

[Tuukka Tolvanen (sp3000)]

confirm, os->all based on w98 dup

Comment 4

[Ludovic Hirlimann]

This bug is still true on W2k+sp3 Build ID: 2003012508.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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?

Comment 6

[Darin Fisher]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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