resuming a dropped connection should be support similar to what ftp does.
Target Milestone: --- → mozilla1.0
Surely this doesn't work on any OS - shouldn't the OS be changed to all?
Target Milestone: mozilla1.0 → Future
*** Bug 208811 has been marked as a duplicate of this bug. ***
*** 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?
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?
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?
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...
Mostly fixed in the download manager by Bug 377243
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...
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)?
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
Any progress here? Or is there a different bug which covers this?
I guess this should be fixed, since Bug 237623 landed, right?
Yes, I believe the fix for Bug 237623 also solved this bug.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 237623
4 years ago
You need to log in before you can comment on or make changes to this bug.