131871 - Implement a way to prevent the loss of downloads when mozilla crashes

Status: RESOLVED DUPLICATE of bug 381157

(SeaMonkey :: Download & File Handling, enhancement)

Description

[Martin Poirier]

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.

Comment 1

[evilmrhenry]

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.

Comment 2

[Ishq Ali]

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?

Comment 3

[Martin Poirier]

By the way, see bug 115903 (I just noticed that!)

Comment 4

[home]

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)?

Comment 5

[Markian Zadony]

*** Bug 180862 has been marked as a duplicate of this bug. ***

Comment 6

[Rich hart]

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!

Comment 7

[Tony Mechelynck [:tonymec]]

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?

Comment 8

[Kim]

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.

Comment 9

[Robert Kaiser]

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.