580247 - "Detach" and "Delete" file attachment operations result in different "attachment deleted" notifications

Status: VERIFIED DUPLICATE of bug 292385

(MailNews Core :: Attachments, defect)

Description

[Christopher Schultz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1

If you "delete" some attachments and "detach" others, you end up with different strategies for notifying the user that each attachment has been deleted.

For instance, I had a message with 4 attachments. The first two files, I chose "detach" to both save to a local file and delete at the same time. The result was the following multipart message parts (I have removed the names of the files and paths and replaced them with "[deleted]"):

------=_NextPart_000_0026_01CB1934.F6ACBAA0
Content-Type: application/msword;
	name="[removed].doc"
Content-Disposition: attachment; filename="[removed].doc"
X-Mozilla-External-Attachment-URL: file:///[deleted]
X-Mozilla-Altered: AttachmentDetached; date="Tue Jul 20 09:57:05 2010"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/msword;
	name="[deleted].doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="[deleted].doc"


------=_NextPart_000_0026_01CB1934.F6ACBAA0
Content-Type: application/msword;
	name="[deleted].doc"
Content-Disposition: attachment; filename="[deleted].doc"
X-Mozilla-External-Attachment-URL: file:///[deleted]
X-Mozilla-Altered: AttachmentDetached; date="Tue Jul 20 09:58:17 2010"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/msword;
	name="[deleted].doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="[deleted].doc"


Next, I simply dragged-and-dropped the remaining two files to their destination, and then chose "Delete" for each attachment. The result was these multipart parts:

------=_NextPart_000_0026_01CB1934.F6ACBAA0
Content-Type: text/x-moz-deleted; name="Deleted: [deleted].pdf"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="Deleted: [deleted].pdf"
X-Mozilla-Altered: AttachmentDeleted; date="Tue Jul 20 10:00:14 2010"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/pdf;
	name="[deleted].pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="[deleted].pdf"


------=_NextPart_000_0026_01CB1934.F6ACBAA0
Content-Type: text/x-moz-deleted; name="Deleted: [deleted].doc"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline; filename="Deleted: [deleted].doc"
X-Mozilla-Altered: AttachmentDeleted; date="Tue Jul 20 10:00:25 2010"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/msword;
	name="[deleted].doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="[deleted].doc"

The multipart parts themselves aren't that big of a deal, except that tb shows one set of them with red X icons indicating that the files are gone, and displays the word "deleted" next to them. The other files (the detached ones) appear to be still available. The "Open" and "Save As..." options are still available.

Reproducible: Always

Steps to Reproduce:
1. Find a message with several attachments
2. Detach one or more files
3. Delete one or more files
Actual Results:  
Message appears to retain the "detached" attachments, while the "deleted" ones look deleted.

Expected Results:  
Consistent behavior from both operations. Also, no options to save already-detached attachments.

Comment 1

[Thomas D. (:thomas8)]

Christopher, thanks for detailed bug report.
However, the different behaviour is intented and looks mostly correct to me:

-> detach: User saves attachment /via TB/ before deleting, and both actions occur in a single operation ("detach"). So TB still knows where the attachment lives on your OS (until you move it). Therefore, TB offers a live link to that attachment, to help you access that file on your OS from TB, and under the assumption that you will not move the file (which is your own choice). The live link has been intentionally designed to look like the actual attachment (as all of your OS shortcuts do). That's intended behaviour, and makes most of this bug "invalid" (Btw, we'll further clarify the difference with better dialogue captions in bug 286283).

- The wrong part is that there is /no/ indication whatsoever that the attachment has been detached from the message (that's bug 292385).
- "Save as" might be borderline, does it actually work?

-> delete: User deletes attachment, and TB does /not/ know where it may or may not have been saved on your OS. Therefore, attachment looks "deleted", and no live link is created (intended behaviour).

- I assume that for drag & drop, TB /cannot/ know where you saved your attachments, as the drop part is handled by your OS. Furthermore, TB /cannot/ know that you want to delete those in a second step. So upon deletion, no live link can be created (intended behaviour).

So most of this bug looks invalid, and the valid part is a duplicate of bug 292385. If there is something wrong about the "save as" action for detached attachments, that would need a new bug.

-> resolving duplicate

Pls let us know if there's something I overlooked.

Comment 2

[Christopher Schultz]

Thomas, thanks for the detailed INVALID resolution :)

I'm okay with this one being marked INVALID as long as there is some visual indication that the attachments are no longer actually attached. Since that's covered by another bug, I'm happy -- as long as the bug eventually gets fixed :)