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 [220.127.116.11]) 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". <3CE8DC77.firstname.lastname@example.org> From: email@example.com (TABATA yusuke) X-Mailer: mnews [version 1.22PL5] 2001-02/07(Wed) Date: Tue, 21 May 2002 23:51:24 JST Message-ID: <020521235124.M0111213@wakame.kmc.gr.jp> X-UIDL: 5CV"!19?"!@p7"!IR^"! Status: U Hi test email with no charset.
trival, future. only happen when default view and default sent are different
Target Milestone: --- → Future
reply to email using default display charset is changed to default composition send format in error updating and confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: reply to email overides default charset and changes to composition format → reply to email using default display charset is changed to default composition send format in error
changing qa contact
QA Contact: jeesun → marina
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?
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
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.
(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.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.