If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Download manager trash button should delete .part files

ASSIGNED

Status

Camino Graveyard
Downloading
--
enhancement
ASSIGNED
11 years ago
5 years ago

People

(Reporter: Peter Yang, Assigned: Chris Lawson (gone))

Tracking

Details

(Reporter)

Description

11 years ago
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.
(Assignee)

Comment 1

11 years ago
Yeah, we should fix this.
Assignee: nobody → nick.kreeger
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Camino1.2

Comment 2

11 years ago
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
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! :)
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*.
Target Milestone: Camino1.6 → ---

Updated

10 years ago
Duplicate of this bug: 420871

Comment 6

10 years ago
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

10 years ago
(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

10 years ago
(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?
(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.
Duplicate of this bug: 471177
(Assignee)

Comment 11

9 years ago
Taking to keep it on my radar. Pretty sure Nick won't mind ;) since I'm almost certain he isn't working on it.
Assignee: nick.kreeger → cl-bugs-new
Status: NEW → ASSIGNED
Hardware: PowerPC → All
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

5 years ago
Still happens with latest Fx nightly.
(Assignee)

Comment 14

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

This is a Camino bug.

Comment 15

5 years ago
Oh, stupid me. Thanks.
You need to log in before you can comment on or make changes to this bug.