Closed Bug 229230 Opened 21 years ago Closed 20 years ago

Pause button in the download manager makes download unrecoverable

Categories

(Toolkit :: Downloads API, defect, P2)

Product:
Toolkit
Component:
Downloads API
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: bugzilla, Assigned: bugs)

References

Details

(Keywords: useless-UI) 

Using the Pause link in the Downloads window apparently cancels the download, as
every time I have tried it I cannot resume the download; after clicking resume
nothing happens and I have to cancel and restart the download.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031217
Firebird/0.7+
I have seen a similary problem.  If during a download I click pause and then
resume the download does not resume.  HOWEVER, if I click pause again the
download does resume.  It looks like the logic may be inverted somewhere in the
code...
investigate later.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Firebird0.10
taking qa
QA Contact: aebrahim
*** Bug 243478 has been marked as a duplicate of this bug. ***
Target Milestone: Firefox1.0beta → After Firefox 1.0
If we're targeting thing for after Firefox 1.0, then shouldn't we remove the
pause UI completely on the aviary_1_0 branch?
Flags: blocking1.0?
OS: MacOS X → All
Hardware: Macintosh → All
*** Bug 245144 has been marked as a duplicate of this bug. ***
My problem seems to be basically that the pause/resume feature doesn't work as
expected. If the download connection fails (server reboot, LAN cable comes
undone/cut, hamster on the wheel at your ISP gets tired, etc.), the download
will seem to keep going but in reality it does not (no amount of pause/resume
makes it restart). This problem also happened to me on Mozilla 1.6 (while trying
to upgrade my dad's machine to Mozilla 1.7, it got disconnected several times).
Basically, what I can tell to get around this is to do the following:
1. When the download fails, cancel it.
2. Do NOT remove the download from the download manager.
3. Start downloading the file again and put it in the same spot with the same name.
4. On Mozilla 1.6, it automatically resumed from where it left off. On Firebird
0.7, the same happened. Since 0.8 and newer have a new download manager, this
"fix" may or may not work. It should, if it's using the same download manager core.
Oh, also. Forgot to mention. Don't use the "Restart download" button. Go to the
site and start from the beginning (with the failed one in the manager still). It
appears to notice partial data and tacks on the end.
Flags: blocking1.0? → blocking1.0+
Minusing until there's a 100% reproducible test case. Renominate then.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Here's how my network is set up: There are three computers, all on a wireless
network, and the main computer is connected to dialup Internet. The connection
is shared with Internet Connection Sharing. With this in mind, you can reproduce
this bug like this:

1) Begin a download on one of the other computers (not the one with the dialup
modem). I tried
http://osdn.dl.sourceforge.net/sourceforge/ignition/ignitionServer_0.3.1-P1.exe
(forgive the advertising :) ).
2) While the file is downloading, go to the main computer and disconnect it.
3) Wait 10 seconds and reconnect it (for Windows to have enough time to think
about it and notify the other computers that the connection was lost).
4) On the machine you were downloading on, the download is now "stuck".
Pause/resume does not function (I think that Pause should *always* break the
connection and Resume should *always* reconnect, which would solve this problem
-- if that's against some HTTP standard, nevermind me), at all. The download
*will not* resume.

The following worked in older versions of Mozilla, but my Internet connection is
being really weird (I can't access SourceForge), so I can't tell you if it works
or not in the latest version (it worked on 1.6 and FF 0.8):

1) Hit cancel on the download that's stuck. Do not remove it.
2) Attempt to re-download the file again, placing it in the same spot as before.
3) The download should resume where it left off.

Of course, you could also break the connection to the server somehow and the
same problem would occur. You know, like cut your LAN cable, unplug your modem,
have your ISP disconnect you, reboot the server you're downloading from, etc.
eew.. I meant that I can't access SourceForge _now_ that I've disconnected and
reconnected. Either way, I can verify and reproduce this bug (sorry about the
double post, I just forgot to mention this and there is no edit button).
*** Bug 249633 has been marked as a duplicate of this bug. ***
*** Bug 234403 has been marked as a duplicate of this bug. ***
Shouldn't this be fixed before 1.0? Resume has never worked for me since the
download manager was implemented. It also thinks a file was compleated if the
connection was terminated and you can't resume/restart those either. Please fix
the resume behaviour before 1.0 thanks.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041021 Firefox/1.0

Can still reproduce. Start a download, lose the link between me and the Internet
(the machine still thinks its connected), attempt to pause/resume the download
when the connection is back, the download doesn't resume.

In this build, however, my workaround in comment 7 no longer works. There isn't
a very easy way to reproduce this with software, but it can be reproduced, so
should we ask for blocking again? It's fairly easy to reproduce:

1) start a download
2) lose the connection between you and the server. unplug your proxy server from
the network, get your Internet Connection Sharing machine offline, reboot the
server. somehow lose the connection to the server without losing your dialup
connection or network connection (you could unplug the cable/DSL modem if it's
plugged into the back of the router).
3) undo what you just did
4) attempt to pause/resume the download. it SHOULD kill the socket and attempt
reconnection, but nothing happens.

I also vote we change the summary to "Pause button in the downloads window does
not function and ends download". It doesn't cancel the download, but the
download becomes unrecoverable, so you have to cancel it and start it from the
beginning.

Ben, this bug should be +, if 1.0 is going to rule for everyone (especially
families with dialup connections and ICS -- my family). If you need more
information, I would be glad to help you.
Hi
Keith, my firefox 1.0pr from 15 october thought the download was finished when I
paused it and killed my internet connection. Firefox also wont ley you exit if
you have downloads in "pause" mode. I think "pause" is more like "on hold" where
firefox wont accept more data but still maintains the http conenction open. If
you kill that, the download is terminated and cant be resumed. Not a nice
solution, every modern download manager like flashget or getright knows how to
deal with http and ftp resumes but sadly not firefox :( Have the developers got
this whole "pause" and "resume" stuff wrong?
On my nightly from today, the same behavior occurs. Only if I unplug the LAN
cable or turn the WLAN radio off, or disconnect from the Internet (if Firefox is
on the same machine as the associated hardware). My dad's machine runs MS
Internet Connection Sharing, and we use that to go through a dialup modem.
Anyways, if it gets disconnected, the download is unresumable.

I'm seriously considering asking for blocking again, but I don't know if we have
enough information for Ben and the rest of them to figure this out. At least we
don't codewise.

If someone else who is experiencing this bug wants, we can ask for blocking
again. I don't want to do it without asking other people CC:'ed to this bug though.

I was going to revise the summary to "Pause button in the download manager does
not function and the download must be canceled", since the pause button doesn't
cancel the download, because it makes it unrecoverable, which makes it where you
have to end it. And only if the connection gets broken but not on the machine in
which Firefox is running (if that occurs, the download shows as "finished",
though it isn't). I can't, because I'm not the submitter, so Joel Nelson needs
to change it. Please? :)
I updated the summary.  Sorry about the delay -- I forgot I was the reporter on
this bug. ;-)

I'm requesting blocking status again.  I do see the bug on my computer, and the
Pause function needs to either be fixed or removed for 1.0; otherwise users will
try it, realize it doesn't work, and switch back to IE or Safari (or other
browser).  

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041022
Firefox/1.0
Flags: blocking-aviary1.0- → blocking-aviary1.0+
Summary: Using the "Pause" link in the Downloads window cancels download → Pause button in the download manager does not function and the download must be canceled
Flags: blocking-aviary1.0+ → blocking-aviary1.0?
Summary: Pause button in the download manager does not function and the download must be canceled → Pause button in the download manager makes download unrecoverable
sorry, I used the wrong flag (+) instead of (?).
I don't think this summary is accurate.  How about "Download cannot be resumed
after connection is lost (even if download was paused)"?
(In reply to comment #20)
> I don't think this summary is accurate.  How about "Download cannot be resumed
> after connection is lost (even if download was paused)"?

I think that is a separate bug.  This bug specifically deals with downloads
having to be cancelled when the Pause button is pressed.
Summary: Pause button in the download manager makes download unrecoverable → Download cannot be resumed
Summary: Download cannot be resumed → Pause button in the download manager makes download unrecoverable
Flags: blocking-aviary1.0? → blocking-aviary1.0-
I think that is two closly related bugs, its not inpossible that they depend on
the same problem source. As I wrote before, if the connection between the server
and firefox is somehow broken, no mather if the download was paused or not,
firefox thinks (almost?) everytime that the download was finished, even as it
previously knew that the file was much larger then that. It could atlease have a
"retry download" if this happens so you don't have to open the properties and
copy the url and start a new download manually.

Thanks
Well, what will happen with all this? Will it be fixed before 1.0? I really hope
it will. Comments someone, Ben?
Any news on this bug? A resume download has never worked for me. Since the
pauze/resume option is offered I think it's important to fix this issue, at this
stage it's not working as expected at all. If there's no plan on fixing this bug
in the near future I think it's better to leave the option to pauze/resume out
for the time being to prevent people from being disappointed.
It's a rather complicated bug from what I can tell. But here's an easy way to
fix it: if the connection times out to the server (destination unreachable or
otherwise) and the connection no longer exists (which is what is happening),
make the download fail. It already fails if you disconnect and it gets a normal
socket disconnection, but it doesn't fail if the destination no longer is
reachable. The problem that is happening is sort of like what happens on IRC if
you lose your connection to the server (but in reverse). If you get bumped
offline for some reason, you'll usually appear as if you have remained connected
to everybody else until either you "ping out", or the destination becomes
unreachable (client reset by peer basically). Mozilla handles it perfectly fine
if the OS closes the sockets (due to disconnection or whatever), but if you're
on a LAN where the gateway can sporadically have an Internet connection, Mozilla
does not know what to do -- it thinks the sockets are open. Even after they've
had plenty of time to time out or get an error message.

One of two things needs to happen before this can be RESOLVED FIXED:
1) Implement a timeout mechanism -- if no bytes are transferred during n period
of time, fail the download. *Note:* This is very undesirable -- some download
servers implement throttling and send only the headers until the client is up to
download the file -- leaving no bytes transferred for quite some time.
2) Handle TCP error messages and fail if it's any of the obvious "you're not
connected to the host anymore" errors.

I'd hack at the code myself, but I don't know the first place to start.
Flags: blocking-aviary1.1?
I get this too.  What I do:
1.  Start downloading a file >1MB (I used this:
http://forum.worldwind.arc.nasa.gov/index.php?showtopic=3262)
2.  When it's about halfway downloaded (make sure there's a part file), click
the "pause" link
3.  Wait about 10 seconds
4.  Click "resume"

My FF (1.0.4) just sits there with the bar where I left it, and I assume will
happily sit there until the apocalypse.  It doesn't move at all.  Really
annoying, especially when I've downloaded 400MB of my 600MB linux ISO...
(In reply to comment #26)
Oh, and if I try to download it to the same place again, it just overwrites my
part file.  Grr.
I know, it does it to me too (didn't try on worldwind, but other places). It's
like it doesn't know to kill the connection (sometimes I can pause, wait,
resume, and have the file downloaded way more) and doesn't know how to start it
back up. Not to mention that if you hit pause, it should unconditionally close
the connection and unconditionally re-connect and re-request the range of data
it needs when you hit resume (which would fix the problem with files dying when
the connection gets snapped between your node and the Internet in addition to
any other problems like yours).

This really should be blocking 1.1. If I had any idea where to start, I'd begin
hacking it.
remove or fix (probably remove, fix in next cycle by implementing real resume)
Flags: blocking-aviary1.1? → blocking-aviary1.1+
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050615
Firefox/1.0+

Anyelse confirm a WFM?
Still a problem.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+

I've been reading around, and apparently, pause stops the channel but leaves it
open (that explains why you can get data while it's paused). This is NOT the
correct behavior! It should close the channel entirely, and when you press
resume, it should re-open the channel. Like every other fscking download manager
I've ever seen.
for the sake of testing, I'm downloading a latest-trunk build of Firefox
(previously I was on Deer Park Alpha 1)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050618 Firefox/1.0+

Still broken.
Keith, are you still seeing the bug that was originally reported here (resume
not working after pause)? Or are you referring purely to the fact that your
download is continuing after you pause?

If the latter, then that's a different bug, not this one. Please try bug 250752
instead.

For my own part, pause and resume seem to work fine for the latest trunk
nightlies on both Mac OS X and Windows XP. Unless you someone can reproduce that
bug with the latest Linux trunk nightlies, I think we can safely resolve this one.

cheers
Apologies. The bug I pointed you to is a Seamonkey bug, not a Firefox one. I
couldn't find one for Firefox specifically, but maybe they share the same root
cause. If they've forked, then I think it should be filed as a new bug, rather
than lumped with this one.

cheers :)
"Still broken" meaning that "after losing my connection, pressing pause and then
pressing resume doesn't resume the download". I can try a Windows trunk nightly
in VMware if you would like. But, and I hope that everyone's understanding this
right, when you press resume, you expect resume to resume under all
circumstances. Obviously, the connection was dropped, so Pause wouldn't do a lot
of good, but Resume should, by all means, attempt to reconnect and start the
transfer over from the point at which it left off if the connection is broken.

As for the "download while paused", it was a Firefox 0.8 bug I noticed and I
haven't seen it since Firefox 0.10, but I was just pointing out that the bug was
a good indication that it's just pausing the channel and not actually closing
the connection. I don't know if it keeps the connection open still, but if it
is, that's probably why resume isn't working (it thinks that it's still
connected, since all queries to the OS to see if the interface is up return
true, even though a TCP/IP connection would fail, so it just tries to run the
code that unpauses the pipe, which isn't the proper behavior at all -- it should
see that a TCP/IP connection was closed and resend all of the data it needs to
connect and resume the download like every other sane download manager on the
planet)

Downloading a latest-trunk win32 nightly, testing in VMware.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050622
Firefox/1.0+

Can still reproduce, just like I can in Linux.
Thanks Keith. Sorry, I wanted to double-check, since you were talking about the
"continuing download" problem earlier.

Pause/resume is definitely functioning correctly for me (and others) now, even
though it didn't used to. I'm using Win XP and have an ethernet connection. At
home I'm using OS X 10.4 and have a standard 56 kb/s dial-up. I wonder what's
different about your system...

I presume your Linux and Windows/VMWare versions use different profiles, so it
seems unlikely that it's due to a bad profile (unless you've happened to install
some weird extension in both versions?). I wonder if it's something unusual
about your network/connection/modem that the Firefox download manager has
trouble with.

Can anyone else using Linux confirm that this bug is fixed or still broken for them?
nope, clean profiles in Windows and in Linux. No extensions, no themes, etc.

here's a quick and dirty way to reproduce this on cable/DSL:
1) connect your computer into a switch or into a port on a residential router
2) connect your cable/DSL modem into the "Internet/WAN" port of your router
3) begin a download.
4) in the middle of the download, unplug the cable/DSL modem from the wall outlet
5) wait a few seconds
6) plug the cable modem back in. your download should have remained in progress
and you won't be able to use Pause/Resume cycling to resume it. this is
illogical, since "Resume" should always resume the download, even if the
connection was broken; it should disconnect the socket if needed, re-open a
connection, and send the proper headers for the length it needs.

here's my setup, it's similar:
1) my computer is connected wirelessly to my router.
2) my dad's computer is acting as a gateway and is plugged into my router in the
Internet port
3) we have a sporadic dialup connection, so my dad's computer sometimes loses
connectivity.
4) if I have a download going inside Firefox and his computer loses the
connection, I cannot under any circumstance resume the download, making
Firefox's download manager useless.

However, my dad runs seamonkey, and if he gets disconnected, the file
immediately fails. similarily, if I unplug my LAN cable or disable ethernet0 in
VMware, the files fail. this isn't really a desired behavior, but it's less
annoying than the current "you have to cancel the download anyways" behavior
(the one that I'm describing and griping about).
Then you're talking about bug 265828 , not this one. This one is WFM.
Well, actually, this bug would be a dup of bug 265828. The OP and I are talking
about the same problem described in bug 265828.
Refer to comment 21. This bug covers a general failing to resume after pause,
which was a common bugbear. That issue now seems to be fixed on Windows and Mac
OS X, and unless someone on Linux can confirm that it's still broken on that
platform, this bug can be resolved.

The problem Keith reports is specifically about a failure to resume after a
network outage (as in bug 265828). The fact the original bug reported here is
gone, while that bug still exists, strongly suggests that they are not the same
thing and shouldn't be duped.
Ah, well, my understanding of this bug was that it's the same thing. Thanks for
the explaination.

I'd say that this is RESOLVED FIXED (resume does work, just only if the
connection isn't broken) then... I just resumed a download. It works (it's laggy
and for some reason it jumped a few KB, but it could have just been data that
was downloaded immediately after I pushed Resume [or it could have been the
jumpyness bug from a long time ago.. dunno which]). And I'm on Linux, so.. -_-

I've already CC:ed myself to the other bug. Hopefully it gets blocking 1.1 and
fixed. The lack of a reliable download manager annoys me :P
Thanks for checking, Keith :) I'll resolve this one and leave the other one for
the networking weirdness.

By the way, that small file size jump you see after resuming is due to
downloaded-but-unprocessed data at the time of pausing. See bug 227516.

cheers
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.