User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817 Build Identifier: (this is part of a split-up of dupe bug 260706 into non-dupe pieces to be tracked from bug 254868) If you have manually set an encoding of a message in messenger to some value and press 'reply to', the encoding inferrence 3-step logic (see bug 260706) is run again, disregarding your manual setting; this is often the wrong choice, since the user's selection of a different encoding usually means that Mozilla's inferrence was wrong. And since changing the encoding in composer no longer has any effect on the quoted message (this could be a bug in itself), we must not countermand the user's choice. Note that this entirely independent of the persistence requested in bug 208917 - there the case is remembering previous user choices when moving from message to message; here the concern is only the current choice, which need be noted by the new composition session. A note regarding encoding coercion: In the case where the "always apply default encoding" preference is set, it would be more reasonable, in the case of replying to a message, to only perform 'relaxing' coercions, that is, assume that the current encoding in messenger is correct, to note the Unicode ranges appearing in the messages, and finally to coerce to the default encoding only if all message characters are represented within it, and otherwise to use UTF-8. Reproducible: Always Steps to Reproduce:

An explanatory note: the coercion has nothing to do with the encoding the message is quoted in. The quoting of the original message is as unicode, and it is not affected by changes to the encoding in the composer window (except that when you try to send, if you have chars from the quoted message which cannot be represented in your selected encoding you'll get a warning). So for the sake of this bug proper, you can entirely disregard "A note regarding encoding coercion".

only the charset for _sending_ the new message is in is now effected by send_default_charset - not the charset for _quoting_ the original message.

Comment on attachment 159718 [details] [diff] [review] fix v1 looks OK - I'd like to have jshin look at this, however...

(In reply to comment #0) > If you have manually set an encoding of a message in messenger to some value and > press 'reply to', the encoding inferrence 3-step logic (see bug 260706) is run > again, disregarding your manual setting; this is often the wrong choice, since Are you sure about this? The mail composition window for reply comes up with the character encoding you manually selected in the message view window unless you turn on 'always use this default character encoding when replying to a message'.

jshin is correct; comment #0 is incorrect. However, the fix is still valid, since when 'always use this default character encoding when replying to a message' is checked, the current code quotes the original message with the default encoding for composing messages rather than with the encoding in which the message is currently displayed. Renaming bug accordingly.

Comment on attachment 159718 [details] [diff] [review] fix v1 r=smontagu, but I second comment 3. If jshin is happy, I'll check this in.

I also noticed this problem (revised :-) in comment #4) while working on bug 258856. I'm happy with and grateful to the patch.

patch checked in.

Comment on attachment 159718 [details] [diff] [review] fix v1 asking for a to branches. Scott, can you check this into aviary-1.0? This should be safe enough.

Comment on attachment 159718 [details] [diff] [review] fix v1 a=mkaply for branches