One of extra advantages of using a 3rd party download manager is that your downloads are still progressing even if your browser crashes. I don't know if the current download manager does this also, but I suspect not, the download manager probably crashes with mozilla. (I can't test this, I can't get my build to crash, which is a good thing). Although this was much more requires when I was on Netscape 4.x, which crashed on me many times a day, the possibility that mozilla crashes is still there and we don't want to restart our downloads from the beginning, especially for users on dial-up. Two possible ways to implement this: 1. Execute the download manager as a separate process, this way a mozilla crash won't take down the download manager. 2. Remember what files were downloaded and keep the downloaded segments in a temporary location along with accurate information of the size of the received segment, so users could pause the downloads and resume them across sessions. This way a crash would still take down the download manager, but the ongoing downloads wouldn't be lost.
This is needed for dial-up connections. At present, if someone calls on the modem line, Windows disconects from the Internet, wrecking all the downloads in progress. As someone who has had ~50mb (several hour) downloads aborted because of this, let me just say that it really sucks. Because of this, I suggest option 2, as there are other reasons to lose downloads besides crashing browsers.
I have noticed the download manager in RC1 and was under the impression that it has some sort of RESUME functionality so if my browser crashed the download will automatically restart with maybe a 10k rollback. But when i tested it, it was not there. This functionality is very necessary for poor dial-up users who disconnect a lot as well. Just an idea, if the mozilla team is too busy with the other bugs (hats off to you guys & gals for all the hard work), can the people who made the Recall add-on do something for download manager as well?
By the way, see bug 115903 (I just noticed that!)
I would say that *both* 1 and 2 should be implemented. That way a browser crash wouldn't jeopardise the download. The download manager should have pause and resume buttons (which are enabled or not depending on the selected download's status). In the event of a crash, the default behaviour should be to pause any downloads. How does this relate to segmented downloads (bug 75360)?
Summary: [RFE] Implement a way to prevent the loss of downloads when mozilla crashes → Implement a way to prevent the loss of downloads when mozilla crashes
*** Bug 180862 has been marked as a duplicate of this bug. ***
A resume button, and a selectionor preference setting to automatically try to resume downloading the file a selectable number of times would be my choice on how to perform this. The download manager is useless without it, IMHO. In the mean time, open up the API to interface with other download managers please!
16 years ago
Depends on: 98288
Assignee: bross2 → download-manager
QA Contact: chrispetersen
Many water went under the bridge in the more than 5 years since the latest comment. What is the status of this bug? Can someone retest it?
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0, not the latest nightly, but the 3.0 release build. Interrupted downloads are now left where they are on the desktop, not destroyed. The file is still left there but can't be resumed (see bug 87151). So far, I've been able to retrieve my downloads partially intact on a disconnect, not quite sure if this would count as this bug being resolved or not, I'd say more fixed partially but it wont be a full fix until its all resolved. I have no way of telling if this is how it works on other builds as well.
As much of this as can be done in SeaMonkey specifically has been resolved with switching to toolkit download manager in bug 381157, so duping to that one.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 381157
You need to log in before you can comment on or make changes to this bug.