146101 - reply to email using default display charset is changed to default composition send format in error

Status: RESOLVED WORKSFORME

(MailNews Core :: Internationalization, defect)

Description

[u32858]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    2002051013

reply to email overides default charset and changes to composition format.



Reproducible: Always
Steps to Reproduce:
1.get an email like the one at the end of this bug, with no defined charset.
2.messenger uses the default as defined in preferences "iso-8859-1" to display
it fine, all good so far
3.click reply, now check the charset and it has changed from that default i
specifed to use when charset not defined to utf-8 (my default send format)

Actual Results:  default charset is forgotten

Expected Results:  should use default charset and not override with my new
compostion of email charset

when i reply to an email with
 
Content-Type: text/plain;
    charset="ISO-2022-JP"

the email is composed in the same format, but in this case as it is not defined
the default is gaken, but it is not used for the reply!! it is some how
forgotten i guess.


From - Wed May 22 11:22:19 2002
X-UIDL: 5CV"!19?"!@p7"!IR^"!
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from wakamxxxx2.kmc.gr.jp (daemon@wakame [192.50.220.6])
	by hasu.boxxxxx.gr.jp (8.8.8/8.8.8/2001-02-02) with ESMTP id XAA00787;
	Tue, 21 May 2002 23:51:35 +0900 (JST)
To: jg@jgxxxrg
Cc: yuxxxxe@kxxxxjp
Subject: Re: mozilla 1.0 party
In-Reply-To: Your message of "Mon, 20 May 2002 20:22:31 +0900".
	<[e-mail]>
From: [e-mail] (TABATA yusuke)
X-Mailer: mnews [version 1.22PL5] 2001-02/07(Wed)
Date: Tue, 21 May 2002 23:51:24 JST
Message-ID: <[e-mail]>
X-UIDL: 5CV"!19?"!@p7"!IR^"!
Status: U

Hi

test email with no charset.

Comment 1

[Frank Tang]

trival, future. only happen when default view and default sent are different

Comment 2

[u32858]

reply to email using default display charset is changed to default composition
send format in error

updating and confirming

Comment 3

[marina]

changing qa contact

Comment 4

[Misha Kruk]

I have a different but related problem and don't know whether it should be filed
separately, so please advise.
Using Mozilla 1.3 on Windows 98 if I do reply to an email with charset like
ISO-8859-2 and then type in some cyrillic characters, when I try to send Mozilla
warns me that I have typed characters which are not valid in the current
encoding. I have KOI8-R set as my default outgoing charset and I expected it to
override the charset of the message I'm replying to. Now that I describe it, I
think that it *is* a bug because I expilictly set my outgoing charset to KOI8-R.
If the current behavior is intended, would a feature request to add a button to
the dialog that pops up "use specified outgoing charset" or maybe "autodetect"
make sense?

Comment 5

[u32858]

Hi

I've seen this "warns me that I have typed characters which are not valid in the
current encoding."  dialog when entering in Japanese.  Basically I believe that
Messenger only uses the default charset (see prefs->mail->composition) for new
emails.  Unless there is somewhere else to force all emails to be KOI8-R  etc?

I think you should file a bug for this as "need a mail pref to force outgoing
charset for email replies"

Anyway, thats my understanding.

Cheers

JG

Comment 6

[Mike Cowperthwaite]

I first looked at this behavior starting with Moz 1.6, after bug 194862 was 
fixed.  The behavior I see is:
 - Composing any message (New, Reply, Forward) will default to the encoding 
specified in the Composition preferences (on the View|Encoding menu)
 - during composition, the message text is handled as Unicode internally

Composing a message from a Template, or creating a message with Edit As New, 
will use the encoding that's specified within that template or message.

On Send, Mozilla scans the text to see what characters are actually in use.
 - if characters exist which cannot be encoded in the selected encoding, prompts 
for Send in Unicode / Don't send
 - if characters fit within common (Western?) subsets of the selected encoding, 
chooses the "smaller" encoding -- that is, will pick US-ASCII if all characters 
fit in 7bit, will pick ISO-8859-1 if all characters are Western, even if 
encoding is specified as UTF-8.

So: it's not clear to me why the original report was a problem.  To my mind, 
Mozilla *should* always use the Composition pref as the encoding for a new 
message, and that's how it works.  JGUK's symptom does still happen, but it 
*always* happens and appears not to be a problem.

JG, if you can confirm that, please mark this bug   Resolved|WorksForMe.

Misha Kruk's symptom -- which seems to be opposite JG's -- does not occur; the 
reply always initially has the specified encoding, even tho the text in the 
message may contain characters that don't fit that encoding.

When sending such a message, the only option Mozilla offers is to send as 
Unicode; see bug 249530.

Comment 7

[Mike Cowperthwaite]

(In reply to comment #6)
> Misha Kruk's symptom -- which seems to be opposite JG's -- does not occur; the 
> reply always initially has the specified encoding, even tho the text in the 
> message may contain characters that don't fit that encoding.

I forgot that a preference had been added to handle this exact case -- in 
Mozilla, Preferences|MailNews|Composition, and in TB, Options|Fonts:
 [] Always use the default character encoding in replies.

So if this preference is unchecked, the original message's encoding is used for 
replies (and inline forwards).  Either way, if the characters from the original 
message or the characters typed in do not fit in the character set specified for 
the composition, the program will prompt to convert to UTF-8.


No response from reporter, so resolving as WFM.  JGUK, feel free to reopen if 
you think I am closing this in error.