Open Bug 254544 Opened 20 years ago Updated 2 years ago

losing connection causes firefox to cancel downloads

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: al.garfield, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Suggestion: Prehaps rather than Firefox canceling all downloads when the connection to the internet is lost (yes some of us are still on dialup :-( ), it would be better if it used the brilliant 'pause' function by default... Reproducible: Always Steps to Reproduce: 1. While downloading a file, disconnect from the internet 2. 3. Actual Results: Got a message box saying "download failed" etc etc etc Expected Results: Paused the download, preferably
related/dupe to 230870?
Reporter, is this still an issue with 1.0?
ex_calibur@operamail.com: Looks like bug 288280 is related to this bug. However, bug 288280 is detected by me under W2K SP4, and I never even experienced a message-box saying "download failed".
No reply from reporter --> wfm Please reopen if you can reproduce this with a trunk build.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Under W2K this is reproducable anytime with a DSL-connection. see bug 288280 for detailed info on how to reproduce.
(In reply to comment #4) > No reply from reporter --> wfm > > Please reopen if you can reproduce this with a trunk build. What is a trunk build, please explain. Ans do you mean the opsys or firefox?
(In reply to comment #7) > U can get Firefox trunk builds here: > ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Thanx. I can reproduce this bug using the TRUNK VERSION Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050330 Firefox/1.0+ under W2K SP4 with DSL-connection. (see bug 288280) So I propose to reopen this bug or assign bug 288280. I do not have any rights to reopen this bug, so I leave that decision to you.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
*** Bug 288280 has been marked as a duplicate of this bug. ***
I've been getting this bug intermitantly as well. It seems to depend on the nightly I'm using. Currently using win XP SP2 FF nightly 20050425 on dlink 802.11g laptop pcmcia card/router dsl connection. Sorry can't remember the previous nightly used when it was not a problem (within the last week tho') reproducable: always download any file and get a XXX.part file. redownload and it completes. It does not seem to be related to a lost WAN connection since it is 100%. I am running Azureus simultaneously (uploading but not downloading)
Bug is still reproducable with latest nightly Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050424 Firefox/1.0+ under W2K SP4 on laptop with ADSL connection. (not wireless). Bug now reproducable as follows: - Start FTP-download (f.i. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-1.0+.en-US.linux-i686.tar.gz) - after a few MB's downloading pull the plug (disconnect from network) - result: error-message (file.part could not be saved...), part-file of a few MB's, failed download status. (expected behaviour up til now) - reconnect to network, when connection re-established activate retry-function in download-manager. - result (NOT expected behaviour): part-file is not re-used, but original filename is now building up on local download location from the beginning, while it should continue building up the part-file right from the point where the connection got lost. - when the connection is not lost again, the download will succeed after a COMPLETE retry (with a left-over part-file), however if the connection in this stage is lost again (start of workaround :-) ) the following (also not expected) situation will occur: The status of the download is suddenly changed to "Done". (???) while it isn't by far. Result on the local download location is then as follows: partial <filename>.part (duh), partial <filename> with status "done" which is offcourse not correct. - Reconnect to the network, wait until connection re-established, remove download (retry not possible offcourse), and restart FTP-download from website. results in errormessage: <filename> already exists, dow you want to replace it?, choose yes, and what do we see? At last, the partfile is building up right from the size it already had before the disconnect, and - at last - the download succeeds as an interrupted FTP-download should, gets the status "done", and the part-file is nicely removed by the downloadmanager. Expected behavior: Retry-function should proceed building up the <filename>.part in case of a FTP-download, in stead of building up <filename>, as mentioned in the last section of the repro, then the above mentioned workaround would not be necessary. In case of a HTTP-download, when the retry-function is activated after re-establishing the connection, <filename>.part should be removed, or maybe better; <filename>.part shouldn't be even used from the beginning, but <filename> should be used directly for building up when starting a new download. Maybe the original idea behind the part-file construction was that the part-file construction should only be used for download-types which can be "resumed"??? Opera does not even use this construction but builds up directly the <filename>, and continues building it up after a stop or network-disconnect. I'm I realy the only one who can reproduce this anytime? Haven't found a nightly which works fine on the point of downloading FTP-files with a lost network connection.
Jerommeke, you're not the only one. Using vanilla Firefox release [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0] and a dial-up, file recovery after a network interupt fails consistently. This is of course terrificly annoying when trying to bring down a large (multi-MB, say 50MB) HTTP file through a small pipe. For me Download Manager inexplicably deletes all traces of the .part file, leaving nothing to show for the connect time. Not so good.
(In reply to comment #12) > Jerommeke, you're not the only one. Using vanilla Firefox release [Mozilla/5.0 > (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0] and a dial-up, Please see the comment #7
Severity: enhancement → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 341409 has been marked as a duplicate of this bug. ***
I added this as a new bug today and it was picked up as a duplicate of this bug. I'm not sure what a trunk build is, but I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 If that helps.
QA Contact: ali → download.manager
Assignee: bugs → nobody
Pausing downloads requires us to keep a connection open with the server, however Bug 230870 can prevent the dialog from cropping up.
Depends on: 230870
Now that cross session resume works, it seems this should be able to work too Right now on latest trunk, cutting off my wireless connection causes the download to go into the failed state. On connection loss, shouldn't we be able to set to the paused state and keep the entityID.
Product: Firefox → Toolkit
Is this still a problem?
Flags: wanted1.9.1?
Flags: wanted1.9.1?
Version: unspecified → Trunk
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b3) Gecko/20091115 Firefox/3.6b3 (.NET CLR 3.5.30729) Source file could not be read error.
Issue still exists in Mozilla/5.0 (Windows; U; Windows NT 5.2; sv-SE; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729) Temporary workaround: 1. Move <file> and <file>.part to another folder. 2. Start a new downoad of the same file 3. Pause that download 4. Move back the old files (overwriting the newly created files) 5. Resume the download Workaround suggested here: http://support.mozilla.com/lt/forum/1/329282?forumId=1&comments_threshold=0&comments_parentId=329282&comments_offset=20&comments_per_page=20&thread_style=commentStyle_plain Duplicates: bug 418608, bug 435799 (linux, has some more info), bug 445543, bug 451953, bug 475703, bug 537452, bug 506648, bug 542167, bug 511581 (solaris) Possibly related: bug 230870, bug 237623, bug 463858,
Affects Firefox 15.0.1 - 2012/09/20 Related: 87151 - suspend/resume does not resume if connection drops The real problem is that if Resume attempt fails, the Resume choice is eliminated and the end-user is ONLY allowed the choice of Restart. The browser should not be making this decision for the end-user. The failure to resume may merely have been due to a transient connection error. New button choices should be [Restart] [Resume] [Stop]. The "temporary workaround" from 2010 no longer works with at least 15.0.1. Substituting the incomplete *.part file is ignored and the hacked resume fails.
This issue is still here in a "nightly build" (version 33) as well.
Do you still see this issue when using a current version?
Flags: needinfo?(worcester12345)
Flags: needinfo?(dmahalko)

(In reply to Wayne Mery (:wsmwk) from comment #26)

Do you still see this issue when using a current version?

Not sure, will have to check.

(This request for information shows you asking the question 5 months ago, but it only showed up in my email recently. Did something change?)

Flags: needinfo?(worcester12345)
Flags: needinfo?(dmahalko)
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mak)
You need to log in before you can comment on or make changes to this bug.