TB 1.6a1-1028, Win2K With the patches for bug 268746 and bug 204350, it is now possible to use the Reply, Forward and Edit As New commands in a message window that's displaying a .EML file or a message/rfc822 attachment. However, if the Subject or From headers have been MIME-encoded, replying to such a message mangles the Subject and To headers in the new composition. (However, CC: and To: headers are copied correctly, in the case of a Reply All.) The exception seems to be if the header is tagged as ISO-8859-1 and/or all its contents fit in ISO-8859-1. This appears to be true regardless of the encoding used by the message itself or for the new message composition -- whether or not either or both are the same encoding as the header in question, the resultant header is wrong. Test message forthcoming.

Steps to reproduce: 1) Save this attachment to disk. 2) Open it from Thunderbird (or Seamonkey) using File|Open 3) In the message window, click Reply All Actual results: To: field (originally Big5) and Subject: field (Windows-1255) are gibberish; CC: fields are OK. Expected results: Characters copied over as displayed in initial message. This message can be further tweaked by changing its charset, and the charset used for the reply can be tweaked in Options/Preferences. I haven't found a combination that preserves either the To: or Subject: header text.

On linux the reply subject becomes only "Re: ". (Tried todays tb2.0 build)

This is another manifestation of what appears to be this bug in T'Bird 2.0.0.17. This simple .eml file has a From: header which is utf-8 quoted-printable encoded and a message body which is utf-8 encoded. When t2.eml is opened in T'Bird, the From and message body display properly, but upon Reply, the To: and ...wrote: in the composition window are garbled.

This message is identical to the attached t2.eml except that the body is iso-8859-1 encoded instead of utf-8 encoded. This message doesn't exhibit the problem.

reply using TB trunk To: field looks good subject jibberish

I see that as well. Mark Sapiro's problem (a different bug) also WFM in trunk.

nsDummyMsgHeader in mail/base/content/msgHdrViewOverlay.js stores 'subject' as decoded text. So decoding the subject in nsMsgCompose::CreateMessage is not needed. I will post a test for this issue later.

The subject in the test is '∀a∊A'.

Comment on attachment 588809 [details] [diff] [review] The test thx very much for the patch, r=me, but a couple nits: + * Test that MIME encoded subject is decoded when replying an opened .eml. + */ +function test_replay_eml_subject() { typo: should be reply_eml_subject, not replay and the comment should be "when replying to an opened .eml file"

Comment on attachment 588589 [details] [diff] [review] Proposed fix thx for the patch and test!

carrying over review+.

http://hg.mozilla.org/comm-central/rev/fc98c220816a http://hg.mozilla.org/comm-central/rev/348640b81582