359181 - Download manager trash button should delete .part files

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Downloading, enhancement)

Description

[Peter Yang]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20061031 Camino/1.2+ (jcraig)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; chrome://navigator/locale/navigator.properties; rv:1.9a1) Gecko/20061031 Camino/1.2+ (jcraig)

The new download manager trash button is great for files that have already been downloaded. If I cancel a download in the middle, however, the trash button is inactive; only the "delete download from list" and "clean download list" buttons are active. I'd like a way to trash the .part file as well.

Reproducible: Always

Steps to Reproduce:
1. Download a file.
2. Cancel the download.
3. Try to delete the .part file using the trash button.

Actual Results:  
The trash button is not active.

Expected Results:  
The trash button should have been active.

I am using a custom jcraig Intel build; however, I believe this is not limited to his optimized builds.

Comment 1

[Chris Lawson (gone)]

Yeah, we should fix this.

Comment 2

[froodian (Ian Leue)]

According to the source, Necko should be deleting this file when the download gets canceled:

http://lxr.mozilla.org/mozilla/source/camino/src/download/ProgressViewController.mm#302

Comment 3

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

Didn't we specifically change it at some point not to delete .part files so that we could be able to resume-from-cancelation-point cancelled downloads?

(We should of course fix *this bug*, but I'm saying the comment in the source might be outdated.) 

P.S. Peter, please don't report bugs against non-official nightlies unless you can reliably reproduce them in official builds (and use the official build when filing the report).  The bug is pretty obvious in this case, but lots of time optimizations and other options introduced in non-official builds can have odd results and lead us to spend QA time tracking down bugs that, officially, dont' exist. Thanks! :)

Comment 4

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

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 6

[Ilya Sherman]

As an alternative, would it make sense to move the .part files to /tmp, and recover them from there if the download is restarted?

Based on my own experience, it is rare that I want to resume a cancelled download, and when I do, the partial downloads are generally small enough that the cached .part file doesn't really help, but I find switching over to Finder to get rid of the extraneous .part files really quite annoying.  Most often, I cancel downloads when I've accidentally clicked the download link more than once, so the partial downloads *really* don't help in that case.

Comment 7

[Håkan Waara]

(In reply to comment #6)
> As an alternative, would it make sense to move the .part files to /tmp, and
> recover them from there if the download is restarted?

Why would you want to recover from what you already downloaded, if you're *restarting* the download? It makes no sense to me. 

Comment 8

[Ilya Sherman]

(In reply to comment #7)
> (In reply to comment #6)
> > As an alternative, would it make sense to move the .part files to /tmp, and
> > recover them from there if the download is restarted?
> 
> Why would you want to recover from what you already downloaded, if you're
> *restarting* the download? It makes no sense to me. 
> 
Sorry, by "restarting" I meant something more like "re-downloading".  As I've gathered form other bug reports along these lines, this functionality is most useful for when the download is cancelled on the user's behalf by e.g. the Internet connection dying, or Camino being closed during a download.  I'm not quite sure how /tmp works, but I'd imagine that the expected lifetime of a temporary file there is long enough for this use case; is that accurate?

Incidentally, I noticed while investigating this bug that there is no way to resume a cancelled download via the download manager interface itself... is that the intended behavior?

Comment 9

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

(In reply to comment #8)
> Incidentally, I noticed while investigating this bug that there is no way to
> resume a cancelled download via the download manager interface itself... is
> that the intended behavior?

Resuming from the .part is bug 215343; (re)starting a new download without the .part (or when the server tell us, "hey, this is done," when it really isn't) is bug 303158.

Comment 11

[Chris Lawson (gone)]

Taking to keep it on my radar. Pretty sure Nick won't mind ;) since I'm almost certain he isn't working on it.

Comment 12

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

This might be as simple as making PVC's |deleteFile|[1] figure out if the download is cancelled (or failed?; see the notifications we send on mUserCancelled and mDownloadFailed in |downloadDidEnd|), and, if so, using a file path with .part instead of a non-.part path.

If so, that would be awesome; I hate this bug!

[1] http://mxr.mozilla.org/camino/source/camino/src/download/ProgressViewController.mm#393

Comment 13

[ojab]

Still happens with latest Fx nightly.

Comment 14

[Chris Lawson (gone)]

(In reply to ojab from comment #13)
> Still happens with latest Fx nightly.

This is a Camino bug.

Comment 15

[ojab]

Oh, stupid me. Thanks.