User Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1 Build ID: 20110608020727 Steps to reproduce: Opened a message that said it had an html attachment. The settings included to display attachments inline. I saw the attachment in the message source window. Actual results: The attachment didn't show up either as an attachment icon in the header or as an inline html page. Expected results: The attachment should have been indicated by an attachment icon and displayed inline as the program setting specified.
Probably a duplicate of Bug 602718 - Inline images not shown in attachment pane when "View>>message body as.plaintext" (after bug 351224, image embedded in multipart/related part is not accessible as attachment) Setting dependency for the time being.
I'm not exactly sure, some more information is needed: - ZIP files definitely aren't inline content of an HTML message, thus bug 602718 wouldn't apply here - is the message body itself HTML format or are you talking about a "real" attachment added to a message which doesn't show up? It would help if you could File > Save As > File (in original EML format) and attach the message here to the bug. Feel free to edit the message in a text editor first to "xxx" over any parts you don't want to post publicly. Or, from View > Message source, copy-paste the main "Content-Type:" heading of the message as well as all other heading before a message part or an attachment (including the "---" boundaries) instead, without posting its full contents.
Created attachment 543620 [details] This is a saved email with an html attachment that didn't appear as described in the bug
Created attachment 543621 [details] This is a spam email with a zipped attachment that didn't appear
The zipped attachment is most likely an undesirable Windows executable, so please take care!
Thanks, this clarifies things. I've changed the content type to plain/text for both examples so that it's easier to examine them safely. The first mail doesn't actually contain an image or other attachment, it's a multipart/alternative construct which offers both plain-text and HTML-encoded parts. The second example corresponds to bug 668259 which was about representing multipart/mixed encodings as multipart/related, thus they do no longer show up with SeaMonkey 2.1 either. The proposed solution as favored in bug 602718 would take care of this issue as well. In agreement with the argumentation in bug 668259, similarly resolving as dupe.