When a mail doesn't have MIME charset info, the display can be corrected by either selecting a proper charset from the charset menu or by setting a proper folder charset. In former case, replying to the mail after the display is corrected by selecting a charset menu, the sender's name is not quoted correctly. The program doesn't pick up the charset that the user has specified from menu. Steps to reproduce: 1. Have a non-ASCII mail w/o MIME header in your mailbox. Make sure the mail has a non-ASCII sender. (I'll attach a testing mail later) 2. Correct the display by selecting a proper charset. 3. Click on Reply. You can see the sender's name is not quoted correctly. 4. Set a proper folder charset to correct the display of the mail, then click on Reply, you won't see this problem.

So the subject does not have the problem?

No, subject doesn't have this problem.

This may be related to bug 118740. Does this work if you override to ISO-2022-JP before the reply?

I don't see this problem anymore on 01/18 build. Marked it as wfm.

This bug is still reproducible on today's build, please reopen. It can't just disappear as result of other bugs fixing. The reason of this bug is as follows: "<author> wrote:" string is generated in QuotingOutputStreamListener constructor: rv = originalMsgHdr->GetMime2DecodedAuthor(getter_Copies(author)); nsMsgHdr::GetMime2DecodedAuthor() calls nsMsgDatabase::RowCellColumnToMime2DecodedString(), but this function checks only folder's override charset to pass to mimeConverter::DecodeMimeHeader(). So, if From: header is not mime encoded we end up with author decoded using iso8859-1 charset (fallback).

Could you attach a testing mail to this report? I still don't see the problem with 01/23 build.Thanks.

Uhm... testcase for this bug is not working for me. When I reply to test message, I get "$BEl[j7r;J(B wrote:" instead of hieroglyphs... (make sure that defauls charset of your folder not set to iso-2022-jp)

Xianglan, i can show you this case on my machine with russian newsgroups

Yes, you are right. Reply doesn't pick up the charset selected from the charset menu. Reopened the bug.

I tried Created an attachment (id=62112) with my debug build and did not see the problem. Xianglan, could you try this with the latest trunk?

I still see this on 01/31 build.

Don't forget - to reproduce this bug, test mail charset and your folder charset must be different

I was looking at the wrong field, it is reproducible.

That field is decoded in the database code which only knows about the folder charset (and folder override). We could do differently in case the message is manually overridden.

Comment on attachment 68935 [details] [diff] [review] Changed QuotingOutputStreamListener to pass charset and charsetoverride to the constructor, also added MimeConverter to the class because it is used in multiple places. Looks good. R=ducarroz

Don't you want to add override charset param to GetMime2DecodedXXX calls? I recall another bug saying that thread pane not updated when one changed override charset. The reason of this bug is exactly the same - GetMime2DecodedXXX calls into msg database functions which uses only folder level charset override. By adding charset parameter to these functions we can fix both bugs :-) (Or may be wtire wrapper function instead? I think code you added is gonna be used in several places :-) )

I did not modified it because the db code does not have to take care per message override which is manually set by UI.

>I recall another bug saying that thread pane not updated when one changed >override charset. Folder level override flag is an attribute which is accessible in the db code. Thread pane not supposed to be updated by the per message override.

>Folder level override flag is an attribute which is accessible in the db code. >Thread pane not supposed to be updated by the per message override. So the only way to get readable display of no-mime message in thread pane is to set folder charset?

yes

Comment on attachment 68935 [details] [diff] [review] Changed QuotingOutputStreamListener to pass charset and charsetoverride to the constructor, also added MimeConverter to the class because it is used in multiple places. sr=bienvenu

I checked in but backed out because the decoder I used returns null if the input is ASCII. I either need to change the decoder to dup the string or change the compose code to check null.

I can't see the difference between the two patches - are you sure you attached the right diffs for the last patch?

Added this comment. + // Decode header, the result string is null if the input is non MIME encoded ASCII. And changed this line. - rv = parser->ExtractHeaderAddressName("UTF-8", NS_ConvertUCS2toUTF8(author).get(), + rv = parser->ExtractHeaderAddressName("UTF-8", decodedString ? decodedString.get() : author.get(),

Comment on attachment 69193 [details] [diff] [review] A new patch, added a check to the decoded header, if null then use the original header string. got it, thx, sorry 'bout that. sr=bienvenu

Comment on attachment 69193 [details] [diff] [review] A new patch, added a check to the decoded header, if null then use the original header string. R=ducarroz

checked in

Verified as fixed.