103766 - Browser hangs after downloading a large file

Status: RESOLVED WORKSFORME

(Core Graveyard :: File Handling, defect)

Description

[Mathieu Johnson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4+) Gecko/20010928
BuildID:    20010928

When you download a large file with Mozilla the browser hangs when
transfering it to it's final location (just after hitting 100% completion).

There's no dialog telling us that it is transferring from cache (like IE)
and all the mozilla windows becomes not responsive (you can't switch between
Mozilla windows either)


Reproducible: Always
Steps to Reproduce:
1. Go to a place where you can download a ~100 MB file
2. Download it somewhere on the hard disk
3. Wait until it hits 100% completion

Actual Results:  The browser hangs for a considerable amount of time
where you can't interact with mozilla (like switching between mozilla windows etc.)

Expected Results:  You can continue using Mozilla as if nothing happened
and/or have a dialog telling you that the file is transfering from cache

Comment 1

[Matthias Versen [:Matti]]

-> XP APPS and confirming with win2k build 20011008..

my Hard Disk is fast (IDE-RAID0) but it's a noticeable delay when the file is moved.

Comment 2

[sairuh (rarely reading bugmail)]

spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)

Comment 3

[sairuh (rarely reading bugmail)]

->bill for retriage

Comment 4

[sairuh (rarely reading bugmail)]

jrgm was kind enough to set up a test file in
http://jrgm.mcom.com/large-file-download/ [sorry, internal to netscape]. that
link will display a directory listing: click on the 95.4M file and select Save.

he is also setting up an ftp version in ftp://jrgm.mcom.com/large-file-download/

Comment 5

[sairuh (rarely reading bugmail)]

is this still a problem?

i cannot repro this using the tests setup by jrgm.

Comment 6

[sairuh (rarely reading bugmail)]

reporter, when you encountered this, were you accessing an ftp or http download
link? also, did you get the helper app/downloading dialog? if so, what was the
mimetype?

btw, the ftp test would be at ftp://jrgm.mcom.com/pub/large-file-download/ and
you would need to bring up the context menu and select Save Link As here.

jrgm has encountered this while setting up the tests, so reopening!

Comment 7

[Bill Law]

->mscott

I suspect that the file move operation that happens when the download completes
is synchronous.  Either we need a way to make that asynchronous, or eliminate it
(but the latter is bug 55690).

Comment 8

[Lars Hugentobler]

you might want to try a slightly altered scenario:
download a large file to a different partition. first stop is either cache or
tempdrive, afterwards it is moved to destination of choice.
for additional fun, you could fill up the tempdrive. regardless of the ample
space on the target mountpoint/partition, the download will abort after filling
the rest of /tmp.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Mike Kaply [:mkaply]]

I messed around with spawning a thread in nsLocalFile to do moves, and it worked 
pretty well.

Couldn't we do this in nsExternalAppHandler::ExecuteDesiredAction() for 
theMoveFile()?

The only side effect I see is that the launch and reveal buttons would have to 
be delayed somehow.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[!Mike]

Same here, 2002091404, Linux, reaches 100% and then just waits. All buttons are
working.

Comment 13

[!Mike]

Working again with 2002092021, Linux, 1.2b. Also mail-attachments are working now.

Comment 14

[Andrei Boros]

On comment #97 in bug #69938 : 

The apparent lock is more extensive then described in #97:

scenario: browser containing only image. (not eve a very large one). Images has 
completed loading.
right click-save image as.
on a P4, 1.9GHz there is a noticable delay (at least .5sec) until dialog 
appears. Why? image should be in cache by now. 
After I press save, mozilla stops responding completely. other browser windows 
if present do not respond if focus requested. scroll bars are unmovable. in 
short: no response. 
after some time (on the average 1.5-2 sec on my box), the save as window 
appears, but in the first stage, only the titlebar and the contour is visible.
after a noticable delay (average .5sec at least), the save as window gets 
painted and in the progress meter I see the striped blue hash filling, often 
drawn broken in several segments. 
after the save as window has closed, there still is a noticable delay until 
mozilla starts responding.

- if I request browser window close while save as window still exists, mozilla 
may stop respoding for anything between 2 and 20 seconds. 
- if I request browser window close immediatly after save as window closed, 
mozilla still does not respond for anything between 0.5 and about 5 sec.
- if I request browser window close about 0.5-1 sec after save as window closed, 
there are good chances that mozilla will, by this time, respond.


Additional information : 
Pentium 4 1.9GHz, 512MB DRAM, 80GB ata-100 ide drive, win98se, radeon7500 video 
card.
I think anyone agrees that this cannot be considered a slow box.
The above behaviour has been tested and observed every time on builds ranging 
from at least 0.9.8 to 1.2b. I often dropped mozilla and used ns4.75 because of 
this.
Having mozilla run in single browser window, single tab as compared to multiple 
browser windows, multiple tabs, or compared to running other applications 
simultaneously with mozilla, even some resource greedy (like easy cd creator 5 
which set's itself for high priority process) make no significant performance 
impact on this behaviour. I mean the delays will only get longer.

As my browsing often implies saving linked files, embedded images, spanning 
10-20 browser windows and tabs in total, this bug imposes a serios performance 
penalty and I simply revert back to netscape 4 to avoid it.

Comment 15

[Max Alekseyev]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Robert Zaleski]

Hey All,
    I downloaded OpenOffice today and had the same problem.  I was running stock
Mozilla 1.5 on XP.  I saved directly to my pen drive.  I knew download was
nearing finish when I was loading a page.  I noticed the page locked while
rendering, and it took me awhile to figure out what was going on.  Went to task
manager, nothing, didn't kill, but I noticed my pendrive light going crazy. 
After a bit it cleared up but mozilla was locked until the copy finished.  Would
be nice if mozilla would go on with life while copying.  Then I couldda browsed
while the copying was going on, instead I nearly killed mozilla thinking it had
crashed.
     I can do some testing with a nightly build if you guys get this worked into
the tree, just let me know.

Comment 19

[Neil Paris]

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

Comment 20

[Barry de la Rosa]

I thought this had been fixed a long time ago. Doesn't happen any more for me.

Comment 21

[Wayne Mery (:wsmwk)]

anyone have link to a large file ~100M file to test with?

Comment 22

[Wayne Mery (:wsmwk)]

WFM downloading  930MB from
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHAPS2/i386/isos/RHEL4-RHAPS2-i386.iso 

FF w2k  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060216 Firefox/1.6a1

SM xp  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060101 SeaMonkey/1.5a