User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070719 Iceweasel/2.0.0.5 (Debian-2.0.0.5-2) Build Identifier: Icedove version 2.0.0.4 (20070622) (debian) On Linux TB writes its attachments in /tmp/ when the user tries to open or save an attachment. Those temporary files are deleted when TB shuts down. However, there is a code path where the temporary files are NOT deleted as they should. This happens when the user double clicks on a mail attachment, selects "Save to disk", click OK, then clicks cancel when prompted for the path where to save the file. Reproducible: Always Steps to Reproduce: 1. 2. 3.

If you cancel on save, how is there any file to delete?

Problem is re-created with Tb 2.0.0.6 and trunk nightlies (MS Win-XP). (1) Double click an attachment (.gif, .txt in my test) => Dialog for start App or Save (a file in tmp is created at this stage) (2) Choose "Save to disk", then OK for dialog of (1) => Dialog for file name (Dialog of (1) remains when Tb 2.0.0.6) (3) CANCEL for file picker dialog of (2) => Dialog of (2) and (1) disappear, and the file in tmp remains This phenomenon looks to be similar to(same?) Download Manager's problem of Bug 300645, although tmp file creator is different; This bug : Thunderbird creates tmp file and calls Download Manager Bug 300645 : Creator of tmp file is Download Manager himself

Yep, looks the same.

(In reply to comment #3) To Magnus Melin: Really DUP? Who is responsible to delete tmp file when CANCEL for file picker dialog? Download Manager who kicked file picker dialog is responsible in any situation?

Haven't looked where and how it's done but I'm pretty certain all that is in shared code.

I also think "is in shared code", i.e. Product=Core, but Bug 300645 is still set as Product=Firefox. Re-opening & setting dependency, in order to avoid loss of Thunderbird case.