92236 - Saving File task and window hang during lengthy downloads

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[[e-mail]]

BUILD: 2001072008 (Linux)
This happened quite a few times when downloading a file from 
www.fileplanet.com. When the file is really large so that the
estimated download time is a few hours, the following happens:
At some point of time, all the info displayed in the progress
window remains the same, i.e. neither the progress bar changes,
nor do the "Time Left" and "Elapsed Time" indicators change.
This seems to stay there like this forever ... there is no
timeout message, no change, nothing.
The file that was created in the temporary directory doesnt
change any more (according to file modification time).
The only thing to do is "Cancel" which will remove the partially
downloaded temporary file.

The odd thing here: even if the connection to the server hangs
(netstat reports it as ESTABLISHED), why doesnt the elapsed time
display update? Maybe it isnt really the connection after all? :)

Comment 1

[basic]

Sounds like networking.

Reporter: could you try with a later build? Are you using proxies?

Comment 2

[[e-mail]]

No proxy used. Will report after some experience with later build.
Anyway, it looks as if the update of the elapsed time display 
(and the time left/percentage) would be triggered by network activity
which is a bad idea if there is none. Elapsed time should be 
triggered by a timing event - it shows time to an accuracy of seconds
and doesnt update for ... in my case ... hours. However that this
doesnt update for several seconds or minutes can be seen more often.

Comment 3

[benc]

->xp apps for now.
Can you provide a specific URL as an example?

Comment 4

[[e-mail]]

I got it for example with:

http://warehouse.videogamebuyer.com/fileplanet/fpnew/gamedemos/adventure/ZaxDemo.exe

But the issue is not the URL, probably any bigger file will do, when the
server or conenction is stale ... my point was that seemingly, if no data
arrives, the elapsed time and other info wont get updated. 

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Reporter: I think this might have been fixed by bug 94231.  Does this problem
still occur in newer builds?

Comment 6

[basic]

maybe a transparent proxy?

does it only happen for http? What about ftp?

Reporter: have you tested this recently? Have you tested this with a recent
build (mozilla0.9.5 or later)? If not please test. If yes and if the bug still
exist, please give more details like answers to the questions above. If the bug
has dissapeared, please mark as resolve WorksForMe

Comment 7

[[e-mail]]

I am seeing this with build 2001100921/linux. No transparent proxy, happened
with ftp. Its hard to test, because
it only seems to occur with big files over a very slow/stalling download link\
and I have to be unlucky to get those.
Another strange thing that might be related is that the download
window (which I usually keep open after the download is complete)
shows strange readouts after the download is complete, for instance:
Download complete (elapsed was 1:48); time left: 0:35; elapsed time 1:48;
progress bar is all dark but shows a readout of 76% 
Is there another bug for these readout quirks? 
Finally: what triggers the update of the readouts in the download window
anyways? Obviously it is not timed, since update frequencies seem
to vary widely and seem to depend on transfer rate?

Comment 8

[sairuh (rarely reading bugmail)]

->file handling

Comment 9

[Bill Law]

This is happening because OnDataAvailable drives our progress dialog and the 
only thing that triggers a "completion" is some state change (via 
nsIWebProgresListener) that doesn't seem to get triggered when these 
connections stall.

This really needs to be fixed.

Comment 10

[Keyser Sose]

Marking NEW not sure why its still unconfirmed.

Comment 11

[Erin Dalzell]

I just ran into this problem downloading a file using W2K build 2001112303. IE
downloads the file just fine....hangs on Mozilla! :=(

Comment 12

[Bill Law]

I'm trying to tighten up the error handling while downloading, which may help 
here.  But I don't have time to spend tracking down vague, obscure error 
conditions.

The only way to get this fixed is for the following to happen:

1. Somebody provides a reasonably consistent means of reproducing a (the?) 
problem.

2. Somebody looks at the networking stuff that's going on and figures out if 
networking code is sending proper notifications to the progress event sink, 
etc. so that the front-end can handle the situation.

3. Finally, I look at the network notifications that are coming in and make 
sure the download/progress-dialog code is handling those appropriately.

->Networking for steps 1&2

Comment 13

[neeti]

cc'ing darin

Comment 14

[[e-mail]]

Bill, doesnt comment #9 actually describe the problem? It was my
feeling right from the start that the problem here is that the update
is somehow triggered by the data received where it should be updated
by a timer event instead. Proposing to change the summary accordingly.

Comment 15

[neeti]

darin

Comment 16

[Joe Blough]

I'm not sure if this is the same problem, but saving as text for CVSWeb
generated pages causes a hanging situation where the Win2K task manager shows
Mozilla using increasing memory.  Here are the specifics:

Win2K machine
Mozilla 1.2.1
A proxy server is being used
This issue does NOT seem to happen in the MFC Embed sample

Steps to reproduce the problem:
Go to http://cvs.wxwindows.org/viewcvs.cgi/wxWindows/samples/validate/validate.cpp
Click on the "download" link on the line "Bookmark a link to: HEAD / (download)"
Right-click on the window opened by this link
Select the menu item "Save Page As..."
Change type to "text"
Press return key

Comment 17

[Darin Fisher]

-> default owner

Comment 18

[Patrick McManus [:mcmanus]]

urls here have long timed out