Closed
Bug 87151
Opened 23 years ago
Closed 10 years ago
suspend/resume does not resume if connection drops
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
RESOLVED
DUPLICATE
of bug 237623
Future
People
(Reporter: dougt, Unassigned)
Details
(Whiteboard: lame-network)
resuming a dropped connection should be support similar to what ftp does.
Surely this doesn't work on any OS - shouldn't the OS be changed to all?
Updated•23 years ago
|
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Hardware: PC → All
Comment 4•20 years ago
|
||
*** Bug 208811 has been marked as a duplicate of this bug. ***
Comment 5•20 years ago
|
||
*** Bug 186491 has been marked as a duplicate of this bug. ***
Comment 7•19 years ago
|
||
*** Bug 245860 has been marked as a duplicate of this bug. ***
Comment 8•18 years ago
|
||
(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•18 years ago
|
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking.http
Comment 9•18 years ago
|
||
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?
Comment 10•18 years ago
|
||
the two bugs are unrelated. that sentence was basically a question to the other networking peers.
Comment 11•18 years ago
|
||
This bug is about suspend/resume on nsIRequest, right? Are those basically unusable, then?
Comment 12•18 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.
Comment 13•18 years ago
|
||
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•18 years ago
|
||
yeah, probably. they ought to try to hold onto the existing connection for as long as possible though.
Comment 15•18 years ago
|
||
So we should probably leave this bug open for doing that...
Comment 16•17 years ago
|
||
Mostly fixed in the download manager by Bug 377243
Comment 17•17 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•15 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•12 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.
Comment 20•12 years ago
|
||
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•12 years ago
|
Whiteboard: lame-network
Comment 22•10 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)
Comment 24•10 years ago
|
||
Yes, I believe the fix for Bug 237623 also solved this bug.
Flags: needinfo?(daniel)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•