Attachment with format=flowed is displayed with <div>. ------=_NextPart_000_7502_1a3f_c07 Content-Type: text/plain; name="NIFBERRY.cgl"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="NIFBERRY.cgl" If you doubleclick this attachment, the content is displayed with: <div class="moz-text-flowed" style="font-family: -moz-fixed">

mail file for test: http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=501

I am surprised that hotmail.com is using format=flowed for plain text mail. You can re-create this problem by doing the following: 1. Access your hotmail.com account. 2. Start composing a mail message to yourself. 3. Attach a plain text file, .txt type, to this message and send it out. 4. Receive this message with Mozilla. 5. Try to see the attached plain text file by double-cliking on the attached file icon or save this file as a .txt file. In either situstion at step 5, you will the extraneous line that does not exist in the file: <div class="moz-text-flowed" style="font-family: -moz-fixed"> I guess we have not built in a logic to deal with MIME part headers for attachments which contain format=flowed attribute like the following typical Hotmail MIME structure: ------=_NextPart_000_7502_1a3f_c07 Content-Type: text/plain; name="testfile.txt"; format=flowed Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="testfile.txt"

I guess the save routine drives libmime with the wrong parameters. It should call it in save mode. Either that or the f=f converter doesn't honor the save mode in that case.

*** Bug 209057 has been marked as a duplicate of this bug. ***

I integrated the sample messages from this bug and from the dupe into my mail, and was able to save the files without seeing the <div> mentioned or any apparent wrapping. => WFM

I have to reopen this -- I was mistaken. The dupe is about saving the attachment to disk, and this bug is about viewing the file. When I originally tested the other day, I am *quite sure* that I was not seeing the <div>, on saving or on viewing (opening into the default text editor, from TB) -- but it's definitely there now. I did, just before re-checking this problem, do something to tweak the text/plain settings in my mimeTypes.rdf file, so I'll play with that some more and report back if I can figure out how to prevent the <div>, as was happening for me before. Note that currently Apple Mail apparently will send out little, empty parts typed as text/plain;f=f -- these are placed interstitially to a bunch of binary attachments in an email (at least, I just saw a message so composed). Opening these little Part1.x items results in a window containing only the <div></div> tags.

*** Bug 228002 has been marked as a duplicate of this bug. ***

(In reply to comment #5) > (..) was able to save the files without seeing the <div> mentioned or any > apparent wrapping. Note: I found that, at least with Mozilla 1.7.8 under WinXP, the files are only packed in <div>..</div>s if you have View->Display Attachments Inline checked. From messages where attachments are not shown inline, they can be saved correctly. Pim

(In reply to comment #8) > (In reply to comment #5) > > (..) was able to save the files without seeing the <div> mentioned or any > > apparent wrapping. > > Note: I found that, at least with Mozilla 1.7.8 under WinXP, the files are > only packed in <div>..</div>s if you have View->Display Attachments Inline > checked. From messages where attachments are not shown inline, they can be > saved correctly. Confirmed. Thanks for the hint!

I get this when replying to attachments.version 2.0.0.14 (20080421)

Using attached testcase ( in comment #1 ) and based on comment #8, I can't reproduce this issue (both when is display attachments inline off\on). Someone can confirm that is WFM?.. or I'm wrong?

(In reply to comment #12) > Using attached testcase ( in comment #1 ) and based on comment #8, I can't > reproduce this issue (both when is display attachments inline off\on). > > Someone can confirm that is WFM?.. or I'm wrong? Test based on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4pre) Gecko/20100412 Lightning/1.0b2pre Lanikai/3.1b2pre ID:20100412031836

(In reply to [:Aureliano Buendía] from comment #12) > Using attached testcase ( in comment #1 ) and based on comment #8, I can't > reproduce this issue (both when is display attachments inline off\on). > Someone can confirm that is WFM?.. or I'm wrong? Thank you, Aureliano! You are right. -> wfm I tested with TB12.0.1 on WinXP, both for "viewing" (open with Editor directly from TB, which requires prior saving anyway), and "saving" (then viewing with Editor): * http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=501 (of comment 1) * attachment 125426 [details] of duplicate bug 209057 Everything works as expected for format=flowed, no extra <div> tags added anywhere.