215343 - Resume canceled/crashed downloads by picking up where stopped, not redownloading entire file (part files)

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Downloading, enhancement, P3)

Description

[Xavier Snelgrove]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030805 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030805 Camino/0.7+

If Camino crashes while downloading files, no matter how close the end of the
download was, you must start anew, it should restart partway through.

Reproducible: Always

Steps to Reproduce:
1.Start a download
2.Quit Camino
3.Reopen Camino

Actual Results:  
The download was aborted

Expected Results:  
Restarted from where it left off.

Comment 1

[Derek Schrock]

Is this a dup of bug 164878?

Comment 2

[James Anthony]

This looks like a dupe of 187483.

Comment 3

[qaz2]

This is does look like a dup of bug 187483.  However, that bug seems to deal exclusively with 
manual restarts, while this one seems to deal with automatically restarting/resuming after 
crash/quit.

So with the word "automatically" added to the summary, this is a valid enhancement request.  To 
clarify: When Camino crashes/is quit in the middle of a download, it should attempt to restart/
resume the download when it is launched again.

Confirmed.

Comment 4

[Josh Aas]

taking

Comment 5

[Mark Leverson]

Im with you Phil. I have had this happen numerous times due to my dialup
connection dropping. This can be very annoying, especially when it is a large
file and it is almost done. Having the ability to pause a download, to make a
phone call then resume, would also be nice.

Comment 6

[Samuel Sidler (old account; do not CC)]

After the pause/resume patch lands, I think Nick (Kreeger) should take a look at
this and see what we want to do. Also, Jasper, do you have any opinions?

Comment 7

[Nick Kreeger]

Maybe using this will help with some MIME problems were having (Java Web Start)?

Comment 8

[Nick Kreeger]

Taking

Comment 9

[Samuel Sidler (old account; do not CC)]

This won't make 1.0.

Retargeting for 1.1.

Comment 10

[Samuel Sidler (old account; do not CC)]

Updating summary to what comment 0 is actually about. :)

This bug is for our implementation of recovering .part files and using them to continue downloads.

Adding bug 87151 as a dependency. It may or may not be the bug we need from Core to make this work, but it seems the most likely open one. Also see bug 107552 which claims to have fixed this back in 2002. The required support may already be there... I'm unsure.

Targeting for Future.

Comment 11

[Samuel Sidler (old account; do not CC)]

Whoops. Didn't mean to WONTFIX this.

Comment 12

[Chris Lawson (gone)]

I noticed something that may be useful in fixing this bug while I was experiencing the problems that led to filing bug 377602.

If you cancel a download, the .part file sticks around, but the download itself gets deleted.

If you later re-start the download, it will jump to where the .part file left off and successfully complete downloading, so in a manner of speaking, we have a rather obtuse sort of support for this already. We just need to hook it up to work automatically, I think.

Nick, any comments? Does what I just said make sense?

cl

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We should probably fix bug 303158 in conjunction with this; see also bug 187483 comment 1 for a high-level overview of the way the UI should work to support both seamlessly (though there might be edge cases for bug 303158 for which we might want, say, a context menu item to force a complete new download).

Comment 14

[Jon]

I've encountered a similar issue, whereby, my download was interrupted when I accidentally closed Mozilla FF.  When I open the browser again, the download in the "download window" appear as failed.  It would be helpful if the user could resume the download.

Mozilla FF 3.0.10 on Win XP SP3

Comment 15

[Chris Lawson (gone)]

This is a Camino bug; you should file a new bug for the problem with Firefox (after first searching to make sure it isn't already filed).

cl