Investigate whether the Download Manager service always deletes the file on disk when canceling a download. See this comment: // XXXben - // If we got here because we resumed the download, we weren't using a // temp file because we used saveURL instead. (this is because the // proper download mechanism employed by the helper app service isn't // fully accessible yet... should be fixed... talk to bz...) // The upshot is we have to delete the file if it exists.

It's possible that a change introduced in bug 593815 causes the Download Manager service to delete the file on disk when canceling, as expected. I still have to test if this really happens in all cases, anyways this patch represents the wanted outcome of removing the calls from the front-end code.

Could you please better explain what's happening now and what will happen after the patch? Looks like here you are trading a toolkit fix for a browser fix, that is not going to work out of the box, unless you have evidence the toolkit code is never hit. Otherwise, if we are changing the toolkit DM behavior we should be really sure we are aware of any downside that may have.

Comment on attachment 630686 [details] [diff] [review] No need to delete the target file in the Download Manager front-end when canceling. see comment 2

Not sure if this is related to what you are talking about, but there's a weird issue concerning cancelled downloads initiated via drag-and-drop: Case 1: 1. Download a file (I tried with the .exe from http://www.mozilla.org/en-US/firefox/channel/#aurora) by dragging the link to the download panel icon 2. Let it finish 3. Click the link to download the file the normal way The download is instantly finished and appears as a copy in the same directory with the correct size and checksum, suggesting it was copied from disk rather than redownloaded. Case 2: 1. Start the download by dragging like in Case 1 2. Cancel the download before it is finished 3. Click the link for a new download The download is again instantly finished, and appears in the folder. It is the same size as the previous file was when the download was cancelled. This to me suggests that something isn't deleted properly when initiating a download via drag-and-drop. The same issue appears in Firefox 15, but as the new Downloads Panel is more drag-and-drop friendly, it's a bigger issue now.

Comment on attachment 630686 [details] [diff] [review] No need to delete the target file in the Download Manager front-end when canceling. Okay, so, having worked on related code, I realize it's not easy to know what happens when a download is canceled, because it depends on what the actual nsICancelable implementation does. The Download Manager back-end sometimes deletes the temporary file, but leaves the main file to nsICancelable. I think we can leave this alone for now. When we rework downloads to be independent from the SQLite back-end, this will likely be addressed in a more consistent way as well.

The new Downloads API takes care of the cases mentioned in this bug, so there is no need to track this for the old Download Manager anymore.