Build: 2003033104-trunk OS: RH8.0 Reply doesn't inherit the charset of the original mail. Forward inline doesn't have this problem. Steps to reproduce: 1. Login to mail. 2. Set default charset for mail composition to a charset which is not iso-8859-1/iso-2022-jp/UTF-8 3. Go to smoketest folder 4. Select any msg in this folder and click on Reply 5. Open View | Character Coding, dot is not marked on the charset of the original mail, instead, it's marked on the charset which was set as the default mail composition charset on the pref window at setp 2. I'm not seeing this problem using 2003033105-trunk Windows build.
According to Marina, this is not happening on Mac build.
I cannot reproduce this on RH linux 8.0. Please be certain that in the Mail $ Newsgroups prefs | Message Display dialog that the "Apply default to all messages (ignore character encoding specified by MIME header)" checkbox is unchecked.
The checkbox on the folder property window is unchecked by default.
It looks like this only happens when the current locale is not supported by C library. My system doesn't have Japanese locale installed properly, so when I launch mozilla in ja_JP.eucJP locale, mozilla gives me an error "Golk-WARNING **: locale not supported by C library". In this case, I'm seeing this problem. On the other hand, if I launch mozilla in C locale or in Ja locale on another machine, the error won't occur and this problem won't be seen. It seems to me, when mozilla is launched in a non-defined locale, it doesn't fall back to C locale, and interesting enough, this will affect Reply.
There is a pref to control which charset (original mail's, or user's default) is used on a reply. I can't test whether this is affected by the locale or not.
Mike, note that this bug had been reported long before that pref. was added. Anyway, I can't see how what's reported could happen. To test, I have to remove a couple of locales on my Linux ....
This may be a dupe of bug 132447.