265828 - Download stops after network interruption. Browser thinks it's still going. Pause/resume does not resume

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[earthasa]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Dial up connection.
Large downloads.
Unattended (but computer is set to auto disconnect on long inactivity and redial
on any attempt to connect).
Some files did not finish downloading, although when I returned the Download
Manager said "Pause" below them and was showing a progress bar, as if they were
still downloading.
Clicking "Pause" just shows "Resume" instead.  Clicking "Resume" does not
resume, but does change link text back to "Pause".
On further research, I find that the temporary files for those downloads are no
longer on the Desktop.

I have had similar problems with downloads in past versions of Firefox all
along, but I should note that I am using a new computer now, with a new OS
install.  I had in the past resorted to using other programs to handle downloads
since one or two hours of wasted download time over a dialup is frusterating.

Thanks~
Asa

Reproducible: Didn't try
Steps to Reproduce:
What I did:
1. Download large number of files, ranging in size up to about 5 mb, over
dial-up connection.
2. Leave computer unattended.
3. Return and find that connection had been broken at some point: unknown if
before or after downloads stopped (my system auto disconnects if no traffic for
period of time).
4. Find that Download Manager indicates some of the files are not finished
downloading.  The link below each file is "Pause", followed by progress details,
NOT "Resume"... as if the downloads were still progressing.
5. Reconnect to the internet.
6. Click Pause below a download.  The link changes to read "Resume".
7. Click Resume below that download.  No resumption occurs, but the link changes
back to "Pause".
8. Look at download folder (Desktop), and notice that the temporary files for
those incomplete downloads are gone.

Actual Results:  
Downloads are incomplete and can't be resumed.

Expected Results:  
1. Automatically resumed the downloads if there was a network interruption
(periodically until success)
2. Not deleted the temporary files since the downloads were not cancelled.
3. Indicated "Pause" under te downloads if in fact they were not bein downloaded
for some reason.
4. Continued downloading on clicking "Resume".

Comment 1

[earthasa]

Attachment: Screen shot

The Download Manager dialog.  The file that still shows progress is how all of
the unfinished downloads looked initially.

Comment 2

[Peter van der Woude [:Peter6]]

kinda dupe of bug 230870 ?

Comment 3

[earthasa]

I don't think it relates to bug 230870 (cross-session resumable downloads),
since this bug is concerned with a single session.  The browser is never closed,
the download manager is never closed.

Today I risked using the download manager again.  It failed.

I started 2 downloads, went in the other room for a couple hours, and returned.
 I was still connected to the internet.  The internet connection was working and
had not disconnected at any time during the downloads.  The download manager
indicated that the downloads were in progress, but in fact they were not.  The
temporary files were gone from the desktop, and all data downloaded thus far was
lost.  I clicked "Pause" then "Resume", and it continued "not to download". 
Clicking "Cancel"/"Retry" restarted the download from the beginning of the file.

The two files being downloaded were: (1) Firefox 1.0 for Windows, (2)
Thunderbird 0.9 for Windows.

I'm currently running Firefox 1.0PR.

Comment 4

[earthasa]

I don't think it relates to bug 230870 (cross-session resumable downloads),
since this bug is concerned with a single session.  The browser is never closed,
the download manager is never closed.  The downloads are never paused.

Today I risked using the download manager again.  It failed.

I started 2 downloads, went in the other room for a couple hours, and returned.
 I was still connected to the internet.  The internet connection was working and
had not disconnected at any time during the downloads.  The download manager
indicated that the downloads were in progress, but in fact they were not.  The
temporary files were gone from the desktop, and all data downloaded thus far
retrieved was lost.  I clicked "Pause" then "Resume", and it continued "not to
download".  Clicking "Cancel"/"Retry" restarted the download from the beginning
of the file.

The two files being downloaded were: (1) Firefox 1.0 for Windows, (2)
Thunderbird 0.9 for Windows.

I'm currently running Firefox 1.0PR.

Comment 5

[Steve Magruder]

I'm seeing this exact same issue with Firefox 1.0 under Win2000.

Comment 6

[daf]

Been having this issue ever since I remember with all versions of Firefox (at
least since the Download Manager appeared, can’t remember passed that), so far
this usually happens in pour connections that result in timeouts, something
Firefox doesn’t seem to handle.

I got broadband from a **** ISP (no choice so far), and I have no issues
downloading from their servers but anything else I risk getting unfinished
downloads.

It’s just a shame the Firefox developers all seem to have good connections or
else this bug would be fixed a long time ago :(

Comment 7

[daf]

Forgot to mention. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050223 Firefox/1.0.1

Could anybody see if this happens in linux or MacOSX?

Comment 8

[daf]

Just searched re-looked Bugzilla and found Bug 211024. I think this is a
Duplicate of it since I think that what's happening is the same issue.

Comment 9

[Mark F Meyer]

(In reply to comment #7)
> Forgot to mention. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
> Gecko/20050223 Firefox/1.0.1
> 
> Could anybody see if this happens in linux or MacOSX?
> 

Yep, running MacOSX10.2.8 (last complete update of Jaguar).
Have never been able to resume an interrupted download under Firefox -clicking
'resume'after 'Pause' has no effect - progress bar looks busy (pulsing/moving
blue)but no progress. Have to 'cancel' and 'retry' which starts all over again
from beginning.   

Comment 10

[daf]

So OS should be set to all, it's at Windows 98 and I use XP and also have the
bug, don't think Linux is any diferent...

Comment 11

[Keith Gable]

see also: bug 229230

I can confirm this on Win2K, Linux, and WinXP, all with a latest-trunk nightly
from 06/22/04. And I have a working testcase for those who are fortunate enough
to have broadband:

Purchase a residential broadband router. Plug your computer into one of the
ports on the router. Plug your broadband modem into the "Internet/WAN" port on
the router. Begin downloading a file, and in the middle of the file, unplug your
broadband modem from the wall outlet. Wait a few seconds (like, 20 seconds), and
plug it back into the power outlet. The download will sit there, doing
absolutely nothing. So, logically, pausing/resuming the download should resume
the download since the connection was broken. However, you can press
pause/resume until you develop carpal tunnel, and it will never resume.

My setup is similar. My dad's computer runs Internet Connection Sharing and is
plugged into the "Internet/WAN" port and acts as my gateway to the Internet. But
the modem in his computer is dialup. So it likes to lose its connection a lot.

And yes, this is a dup of bug 229230 or it's a dup of this... -_-

Someone ask for blocking. This really needs to be fixed. It's never good to have
to say "Firefox's download manager sucks"... and yet, for the people I know with
dialup connections and ICS, that's exactly why I have to install ReGet...

Comment 12

[earthasa]

Thanks Keith for the easy step to reproduce.
I'm the original submitter, now runner XP, now with broadband.  Running FF 1.0.4

I followed your instructions and saw that the problem still exists.  Only
difference from what I saw before: the partially downloaded file was not deleted
by Firefox while the download was stalled.  (Possibly it is deleted after an
extended period of time..., or this element was fixed.)
URL that gives plenty of time to unplug your modem:
ftp://suse.cs.utah.edu/pub/suse.com/suse/i386/current/iso/SUSE-Linux-9.2-FTP-DVD.iso


I unplugged the router from my modem rather than the modem from the wall..
easier to get back online immediately.


I'm really surprised that this bug hasn't been assigned yet.  I have experienced
it for at least two years!  I'm sure it affects lots of users, especially those
on dial-up.

I'm not sure how exactly to request blocking.  I'll try just selecting it here.

Comment 13

[Keith Gable]

In the Flags on the right, put a ? mark in "blocking-aviary1.1" and commit the
bug (don't pick anything else; 1.8x refers to Gecko [and this is
Firefox-specific, because Seamonkey's download manager is different], and 1.0.x
refers to security updates). That'll make some reviewer/super-reviewer see the
bug (they can search for all bugs with blocking-aviary1.1? and approve/deny it).

Anyways, yes, I'm on dialup, and it's fairly annoying for Firefox's download
manager to be unreliable (I have to use KGet to download stuff because I'm
afraid I'll lose my connection and be unable to resume the download and have to
start OVER from the beginning...).

If any QA people want me to, I'm able to test on Linux i686 (Gentoo), Windows
2000 Pro SP4, and Windows XP SP2 with the same exact Firefox configuration
running on the same computer (VMware) and I'm fully aware of how to get
nightlies and such :P.

FYI: The reason my testcase required unplugging the modem from the power outlet
is because I've seen routers that can detect when you unplug the cable and do
things when you do (which could possibly aggrevate the testcase), but if you
leave the cable in and unplug it from the wall, it detects the cable as "still
there" but you have no way to communicate outside the network (modem is
disconnected). Plus, it simulates a "lost connection" better :P

Oh, and if any R/SR/QA people need me to, I can record a video in VMware of the
behavior being described.

Comment 14

[Keith Gable]

and apparently this isn't a dup of the bug I mentioned, so ignore it. they're
apparently two seperate bugs.

Comment 15

[Wayne Woods]

Bug 229230 (now fixed) wasn't quite the same thing, as that dealt with a general
issue of pause/resume failing. Updating the summary of this bug to focus on the
fact that it's only about downloads hanging after a network interruption. Does
it sound about right to you guys?

Also requesting a 1.1 block to at least get it on the radar for whoever's
working on download issues.

Comment 16

[Wayne Woods]

Please forgive me if this isn't the right product/component...

Comment 17

[earthasa]

(In reply to comment #16)
> Please forgive me if this isn't the right product/component...

I'm not the one to answer that, of course, but whether it's a core issue or a
Firefox issue, it relates to bo FTP and HTTP transfers.  So the HTTP component
doesn't sound right to me.

Comment 18

[daf]

Why was this changed to blocking-aviary2.0?

Comment 19

[Keith Gable]

Two words: Holy ****.

Looks like I'm stuck with wget (or KGet) until next year, fellas. But, uh,
geez.. surely this isn't that hard to fix, and at that, surely this is important
enough /to/ fix? Us Linux users don't really care, but wtf will the Windows
users think? "WAA! FIREFOX HAS A BROKEN DOWNLOAD MANAGER! WAA!!!!111one!!" ..
ask my grandma.

I mean, I'm not going to argue with a r/sr/qa or anything. I'm just saying that
if you got the right people looking at this bug they surely could fix it, or at
least make it totally fail the download, so it seems less like Firefox is broken
and more like the connection is broken (which IS what's happening)

Comment 20

[Mike Connor [:mconnor]]

Not sure I meant to plus this, pushing this back to nomination and moving to Gecko.

Comment 21

[maenneph]

My testing shows that this bug does not only affect HTTP connections but also FTP connections. Somebody might want to change the component this bug is assigned to. I also don't think that this bug is a WAN/Dial-up/broadband specific issue but more of a general problem with TCP as I was able to reproduce it on my linux machine by using just the loopback interface (localhost) and blocking the traffic with iptables in the middle of the transfer (tested with FTP, not yet with HTTP). 

How come this bug has no target milestone?

Comment 22

[Darin Fisher]

Not going to block 1.8.1 for this, but we'll happily consider a baked-on-trunk patch.

This sounds like it might actually be more of a download manager bug.

Comment 23

[lars noodén]

This bug or one like it exists in more recent versions as well:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

Comment 24

[Wayne Mery (:wsmwk)]

is this known to still exist?

Comment 25

[Lorenz Froihofer]

(In reply to comment #24)
> is this known to still exist?

Just tried it:

1. Start large download
2. Disconnect from network

Expected behaviour: 

Firefox pauses the download and allows to resume after the reconnection.

Actual behaviour:

Download is stopped and shown to be complete. In the tray area, a box showing "Downloads complete -- All downloads have finished successfully" is shown. The part of the file downloaded before the network interruption is stored on disk.

--> The behaviour is different from the original report, but network disconnections are still not handled correctly.

Comment 28

[Patrick McManus [:mcmanus]]

bagder - do you think your network change code would fix this? (plz resolve if so)

Comment 29

[Daniel Stenberg [:bagder]]

Comment 23 from 2007 is the last claim to have seen this problem. Comment 25 mentions the problem changed and turned into an issue with the download manager - sounding very much like a problem we've since fixed with better detection of premature disconnects.

Based on this, I consider this issue fixed.