260725 - quoting a message for a reply must maintain user's display encoding selection

Status: RESOLVED FIXED

(MailNews Core :: Internationalization, defect)

Description

[Eyal Rozenberg]

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:

Comment 1

[Eyal Rozenberg]

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".

Comment 2

[Eyal Rozenberg]

Attachment: fix v1

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 3

[David :Bienvenu]

Comment on attachment 159718 [details] [diff] [review]
fix v1

looks OK - I'd like to have jshin look at this, however...

Comment 4

[Jungshik Shin]

(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'. 

Comment 5

[Eyal Rozenberg]

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 6

[Simon Montagu :smontagu]

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.

Comment 7

[Jungshik Shin]

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

Comment 8

[Simon Montagu :smontagu]

patch checked in.

Comment 9

[Jungshik Shin]

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 10

[Mike Kaply [:mkaply]]

Comment on attachment 159718 [details] [diff] [review]
fix v1

a=mkaply for branches