suspend/resume does not resume if connection drops

RESOLVED DUPLICATE of bug 237623

Status

()

defect
RESOLVED DUPLICATE of bug 237623
18 years ago
4 years ago

People

(Reporter: dougt, Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: lame-network)

Reporter

Description

18 years ago
resuming a dropped connection should be support similar to what ftp does.

Comment 1

18 years ago
mozilla 1.0
Target Milestone: --- → mozilla1.0

Comment 2

18 years ago
Surely this doesn't work on any OS - shouldn't the OS be changed to all?

Updated

18 years ago
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All

Comment 3

18 years ago
-> future
Target Milestone: mozilla1.0 → Future

Comment 4

16 years ago
*** Bug 208811 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
*** Bug 186491 has been marked as a duplicate of this bug. ***
186491 was duped so shouldn't be blocker
No longer blocks: 186491
*** Bug 245860 has been marked as a duplicate of this bug. ***
(In reply to comment #0)
> resuming a dropped connection should be support similar to what ftp does.

well, FTP doesn't do that anymore. isn't this bug WONTFIX, because callers should use nsIResumableChannel?

Updated

13 years ago
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking.http
biesi in comment #8)
> (In reply to comment #0)
> > resuming a dropped connection should be support similar to what ftp does.
> 
> isn't this bug WONTFIX, because callers should use nsIResumableChannel?

is this a statement or a question to ____ ?

related to Bug 227113 / Bug 93055?
the two bugs are unrelated. that sentence was basically a question to the other networking peers.
This bug is about suspend/resume on nsIRequest, right?  Are those basically unusable, then?

Comment 12

13 years ago
they work for short intervals.  if you suspend for 5 minutes, you might find that the server has dropped the stalled connection.

FWIW, FTP no longer creates a new connection when the suspended connection is dropped.
Would it make sense for resumable channels to behind the scenes store whatever info is needed to use nsIResumableChannel::ResumeAt when Suspend() is called and then do a ResumeAt() when Resume() is called?

Comment 14

13 years ago
yeah, probably.  they ought to try to hold onto the existing connection for as long as possible though.
So we should probably leave this bug open for doing that...

Updated

13 years ago
Blocks: 18004
Mostly fixed in the download manager by Bug 377243

Comment 17

12 years ago
Tryning to download http://ftp.mozilla.org/pub/mozilla/VMs/CentOS5-ReferencePlatform-rc1.zip (1.1Go)
If I manually pause the download, I can choose resume and it works.
But after 50% download, connection broke (wifi wen't down on my side for a few seconds) -> Impossible to resume. The only choice is restart.
So may be the network code can resume but the user has no mean to resume then the connection breaks...

Comment 18

10 years ago
Does this still happen on the toolkit download manager of 1.9.1 tree or newer (i.e. Firefox 3.5, SeaMonkey 2.0 after today, or newer)?

Comment 19

7 years ago
Applies to Firefox 15.0.1 - 2012/09/20 - "Firefox is up to date!"


What the? This is a TWELVE YEAR OLD bug? That's some awesome Rapid Release you got there, devs.

Let me explain how this bug affects me in modern 2012 terms.

SCENARIO:
1. Someone else's laptop on a wifi connection is set to go to sleep after 60 min even when plugged in (doh)
2. Cellular EVDO Wifi tethering/hotspot, sloooow
3. Huge software installation download, takes hours
4. Laptop goes to sleep, download pauses

THE PROBLEM:
5. Wake up laptop, Firefox window appears
6. End-user immediately clicks Resume download. 
7. Connection error due to Wifi not ready.
8. Download has failed. You just lost everything.
9. Can not attempt to resume again when the wifi connection finally comes back up and is ready 12 seconds later.

The only download option now is to completely start over. Wow, thanks for wasting an hour of my time Firefox.


THE SOLUTION:
@ If the attempt to resume fails, ALWAYS give the user the choice of whether to try to Resume again or Restart. DO NOT MAKE THE DECISION TO ONLY ALLOW RESTART, FOR THE END USER. 

@ If the attempt to resume fails, change download button choices to [Restart] [Resume] [Stop], with Resume and Stop in the normal button alignment positions in the Downloads window, and Restart being further to the left so that it doesn't fall directly under the cursor if the resume attempt just failed.
In reply to comment #19:
- See https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and in particular steps 1.1 and 1.2.
- If you know how to fix this bug, go ahead: ASSIGN it to yourself, attach a patch, have it reviewed, etc.; see https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch

Updated

7 years ago
Duplicate of this bug: 788952
Whiteboard: lame-network

Comment 22

5 years ago
Any progress here? Or is there a different bug which covers this?
I guess this should be fixed, since Bug 237623 landed, right?
Flags: needinfo?(daniel)
Yes, I believe the fix for Bug 237623 also solved this bug.
Flags: needinfo?(daniel)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 237623
You need to log in before you can comment on or make changes to this bug.