User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0 Build ID: 20120129021758 Steps to reproduce: I receive an email at work with Outlook that should have been sent to my home email. I forward the email home as an attachment. Actual results: When I get home I want to drag the attached email from it's parent email directly into the inbox, but it doesn't work. If I save the email to the desktop either with save or detach, I am unable to drag the file and drop into my inbox. I discovered if I rename the file to end with .eml I can do that. Expected results: I should be able to drag an attached email directly from the parent and drop into a message list. If an attached email is saved out of the parent to desktop, the filename extension should be forced as .eml so Thunderbird will know what to do with it. If saving several attached emails to a folder, all files created should end with .eml.

This should be a fairly easy fix. All the functionality is apparently there. The way Thunderbird works with attached emails is screwy, as if the use has never been fully addressed. Thanks

Sometimes when saving or detaching it does save with .eml, but not always. Saving multiple attached emails from one parent into a folder does not save any with .eml. This was a severe pain until I figured it out. I even went so far as saving the entire parent as a text file, cutting and pasting boundary layers, then dropping into inbox.

(In reply to David McDivitt from comment #2) You are reporting 2 bugs IMO; the 2nd one is addressed in bug 414865.

This is not two issues and different from 424865. When dragging the attached email out of the parent email and dropping on the desktop, the file name extension given the created file is inconsistent. An attached email is not the same as other types of attachments, as say a file attachment. A file attachment carries with it the name the file should have when extracted. An attached email is not a file and therefore has no default name. If a parent contains several attached emails and all are saved to a folder, the email subject is used as the file name for each, and none are given a file name extension. If a parent contains several and only one is saved, the same holds true. But if a parent has only a single attached email it is given the default name ForwardedMessage.eml. If an entire email, any email, is saved with file/save-as, the subject is used as the file name with .eml appended. What I am describing here is the inconsistency given the file name when saving an email stream to the desktop. Sometimes it has .eml, sometimes not. Having said all that, when the attached email is dragged from the parent and dropped somewhere, maybe a Thunderbird message list, it does not work because the file name assigned to the drag/drop operation does not end in .eml, and Thunderbird does not recognize what it is, even though the drag operation originated from within Thunderbird itself. I am somewhat familiar with the Windows drag/drop API. Though the attachment is being dragged from a message, Thunderbird has to receive it as if dragged from Explorer or the desktop. I think if the file name and extension issue is looked into, the problem of saving attached emails would be resolved as well as dragging an attached email and dropping into the Thunderbird message list. I don't think it would take much work because all necessary functionality is apparently present.

(In reply to David McDivitt from comment #4) > I think if the file name and extension issue is looked into, the problem of > saving attached emails would be resolved as well as dragging an attached > email and dropping into the Thunderbird message list. I don't think it would > take much work because all necessary functionality is apparently present. Let's leave that conclusion to people who are familiar with the code in question (e.g. me). This is definitely two different bugs. First, the issue of drag-and-drop within Thunderbird is bug 11013. It requires updating nsIMsgCopyService, which is straightforward but will require some refactoring. Second, the issue of attachment naming when there are multiple attached messages. That's totally separate, and doesn't appear to have a dupe, but I can't reproduce the issue.

David, thanks for your input on improving attachments UX. - I believe I mostly agree with your ideas, but we need to present them as separate reproducable items with one issue per ticket, and then check if these issues have already been filed or fixed. - Each ticket needs concise and detailed STR, Actual and Expected Behaviour in *list* form - please avoid too much prose especially in the initial description as it's too hard too parse. Any bullets/numbering/etc. will help to focus your points and help your readers parse your inputs and refer to them more easily. (In reply to David McDivitt from comment #0) > Actual results: > When I get home I want to drag the attached email from it's parent email > directly into the inbox, but it doesn't work. That's a duplicate of bug 11013. > If I save the email to the > desktop either with save or detach, I am unable to drag the file and drop > into my inbox. I discovered if I rename the file to end with .eml I can do > that. Yeah. Again, too many issues in one block, and it's not very clear what you're talking about, for lack of clear STR. IMO the behaviour described is not very surprising, but might make a good RFE (which needs a new bug): STR 1) view msg with following attachment (attached msg without .eml extension): >Content-Type: message/rfc822; > name="Attached Message" >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename="Attached Message" 2) Save "Attached Message" to Desktop (or any OS file folder) a) Save all/Save as/Detach etc. from context menu, OR b) Drag from attachment pane to Desktop Actual result after 1): - attached msg presented nicely in message reader (view attachments inline) - so TB sees the message/rfc822 header and acts accordingly after 2a): - any non-drag method of saving of "attached message" as a file will save it "as-is", i.e. without adding .eml extension. So dragging the very same "attached message" file from your back into TB will fail unless you rename the file with .eml extension first. This is inconsistent with 2b), and we should be more helpful (needs new bug). after 2b): - dragging "attached message" to Desktop will helpfully add .eml extension to the file name if there is no extension: - mime: filename="attached message" (extension missing) - after dragging to OS folder: File "attached message.eml" (TB adds extension) Expected for cases of 2a) (non-drag methods): helpfully add .eml extenstion (as we do for 2b drag method): for attachments of mime type message/rfc822, automatically save "attached message" (without extension) as "attached message.eml" (with added extension) That's a reasonable RFE, which needs a new bug if there isn't one yet. > Expected results: > > I should be able to drag an attached email directly from the parent and drop > into a message list. That's bug 11013. > If an attached email is saved out of the parent to > desktop, the filename extension should be forced as .eml so Thunderbird will > know what to do with it. If saving several attached emails to a folder, all > files created should end with .eml. Yes, as described above.

Short summary: I'll close this bug for the following reasons: - current summary ("drag attached email into folder") and description are ambiguous (OS folder, TB mail folder, or both?), and not actionable ("drag attached email into folder" - what's the bug or RFE about that?). - biggest problem (can't drag attached msgs to TB-folders) is covered in bug 11013 (-> duping) - problem of "ux-inconsistency when saving vs. dragging attached msg without .eml extension to OS folder" (comment 6) needs a separate bug - problem of "Thunderbird wrongly uses same (and useless) filename "Attached Message" for multiple forwarded messages, but only if *dragged* to composition's attachment pane" is Bug 209629 - afasics TB is well-behaved for all other scenarios referred to in this bug (as I shall show below). -> duplicate of bug 11013 ------------------- TLDR analysis of reporter's comments (In reply to David McDivitt from comment #4) > This is not two issues and different from 424865. When dragging the attached > email out of the parent email and dropping on the desktop, the file name > extension given the created file is inconsistent. An attached email is not > the same as other types of attachments, as say a file attachment. A file > attachment carries with it the name the file should have when extracted. An > attached email is not a file and therefore has no default name. I don't know what other mailers do, but for TB, there is no difference between a message/rfc822 attachment and other file attachments: In TB, message attachments are "normal" mime attachments that come with a predefined filename (with or without .eml extension) >Content-Type: message/rfc822; > name="foobar[.eml]" >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename="foobar[.eml]" Of course, subject is the most appropriate filename when forwarding messages, and that's what we do for the majority of cases when *composing*, send them as "subject1.eml", "subject2.eml" etc. When *receiving*, we have to respect the (file)names as set by sender, so if sender has "ForwardedMessage" as filename, we have to accept that (while adding .eml if there's no extension). > If a parent > contains several attached emails and all are saved to a folder, the email > subject is used as the file name for each, and none are given a file name > extension. If a parent contains several and only one is saved, the same > holds true. Well, not quite. When parsing received messages in *Message Reader*, it all depends on the mime headers of the attached message(s). But indeed, TB is smart enough to use subject of attached msg as makeshift filename if (and *only* if) *no* (file)name is present in the mime header. Otherwise, *saving* (vs. dragging) will save the file exactly with the specified filename (with or without extension; I tested with the following windows setting *unchecked*: "Don't show extensions for known file types"). Dragging will add the extension .eml if it's missing. Apart from comment 6, imo this all works as expected. TB mime header parsing for *received messages* with message/rfc822 attachments in message reader: a) full mime header >Content-Type: message/rfc822; > name="Attached Message" >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename="Attached Message" -> attachment filename (drag): "Attachmed Message.eml" -> attachment filename (non-drag): "Attached Message" (adding .eml here to be consistent is the RFE described in comment 6 which needs a separate bug) b) mime header with name, but without filename >Content-Type: message/rfc822; > name="Attached Message" >Content-Transfer-Encoding: 7bit -> same as a) c) with filename, but without name >Content-Type: message/rfc822; > name="Attached Message" >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; -> same as a) IMO, that's correct behaviour: - For *received* msgs, TB has no reason to assume that "Attached Message" is not the intended (file)name of the attachment. It's really up to the sender to define a better filename that reflects the subject of attached msg, or to ensure that different attachments have different filenames. - For *composing*, TB fails only for the case of Bug 209629. d) if filename is different from name, filename takes precedence Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Different Filename.eml" -> attachment filename (drag/non-drag): "Different Filename.eml" e) mime header without any (file) names specified: >Content-Type: message/rfc822; >Content-Transfer-Encoding: 7bit -> attachment filename (drag/non-drag): "subject of fwdd msg.eml" This is where TB is really smart to use the subject as a makeshift filename in message reader (and imo the only legitimate and reasonable scenario for doing that with received msgs). ***************** Generally speaking: *Message reader* derives attachment file name (for saving) from the following sources: - filename if present (takes precedence over name) - name if filename not present - subject of the actual attached message only when both filename and name are missing (or if sender specified subject as filename and/or name) ***************** > But if a parent has only a single attached email it is given the > default name ForwardedMessage.eml. I cannot reproduce that in TB16, at all. - select single msg, Message > Forward as > Attachment -> mime-filename of attached msg is: "Subject of forwarded msg.eml" We do have a problem when *dragging* existing message(s) into composition's attachment pane, that's where *each* of one or more attached msgs wrongly get same filename="Attached Message" (without .eml extension), which is a problem in many ways, e.g. for "Save all", they will overwrite each other unless manually renamed. That's Bug 209629. > If an entire email, any email, is saved > with file/save-as, the subject is used as the file name with .eml appended. > What I am describing here is the inconsistency given the file name when > saving an email stream to the desktop. Sometimes it has .eml, sometimes not. I think that's just rephrasing of what we covered above. > Having said all that, when the attached email is dragged from the parent and > dropped somewhere, maybe a Thunderbird message list, it does not work > because the file name assigned to the drag/drop operation does not end in > .eml, and Thunderbird does not recognize what it is, even though the drag > operation originated from within Thunderbird itself. That's another repetition of bug 11013, so it's covered. Btw, just having filename="foobar.*eml*" does *not* enable TB-internal dragging. > I am somewhat familiar > with the Windows drag/drop API. That's great! So David, perhaps you can try to fix bug 11013? Any help will be appreciated. > I think if the file name and extension issue is looked into, the problem of > saving attached emails would be resolved as well as dragging an attached > email and dropping into the Thunderbird message list. I don't think it would > take much work because all necessary functionality is apparently present. Regardless of how much work this is or not (not easy to tell), the main problem is manpower. More so, we need to have concisely defined bugs so that those who are able can address them efficiently. Bugs with fuzzy descriptions and/or more than one issue per bug will never get addressed. So there's no point in keeping this bug.

(In reply to Thomas D. from comment #7) Sorry, there's a mime line missing here: > c) with filename, but without name > >Content-Type: message/rfc822; > > name="Attached Message" > >Content-Transfer-Encoding: 7bit > >Content-Disposition: attachment; filename="Attached Message" > -> same as a) -> attachment filename (drag): "Attachmed Message.eml" -> attachment filename (non-drag): "Attached Message" (adding .eml here to be consistent is the RFE described in comment 6 which needs a separate bug) IMO, not using the subject of attached msg here is correct behaviour: > - For *received* msgs, TB has no reason to assume that "Attached Message" is > not the intended (file)name of the attachment. It's really up to the sender > to define a better filename that reflects the subject of attached msg, or to > ensure that different attachments have different filenames. > - For *composing*, TB fails only for the case of Bug 209629.