User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: trunk Under the Fonts & Encodings tab, an option named "Apply default character encoding to all incoming messages" exists. Not sure what it was originally supposed to workaround, but this option seems to cause Thunderbird to ignore all valid RFC-compliant MIME headers and blindly display all messages in selected encoding. This option was probably useful in early days when MIME support was sparse and users have used non-ASCII charsets without properly declaring them in MIME headers. However, today MIME adoption is almost universal - and this option is actually causing serious RFC breakage and encoding problems. Many users don't fully understand what this option is actually doing and check it in an effort to fix wrong encoding on single email - then run into much severe trouble since proper MIME headers are with this option ignored for all valid cases. Thus this option is nowadays doing serious harm to the email system and needs to be completely discontinued. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Thunderbird should always honour MIME headers.

Was implemented because of bug 43101. I wouldn't know if that's still an issue, but one would guess no, and the UI for it should go.

Thanks for the clarification. Anyway, the fix for bug 43101 was not the right one - the user was complaining about encoding is single newsgroup (alt.chinese.text), but this option sets the encoding for everything - i.e. all emails and all newsgroups. Thus with this option activated, it is not possible to read email and/or english newsgroups... What this user actually needed was an option to set default encoding for specific newsgroup - and I believe it is now possible. So the global option really needs to be removed as it does not address even the original problem correctly.

For (further) reference, mailnews.force_charset_override was bug 43101. Per folder charset: bug 31058, UI for it: bug 32714, then bug 65018. I do wonder if even the folder charset has any users now in late 2007 - at least for mail, based on those bugs I imagine news is more problematic. ccing wada: maybe you have input on this from Japanese point of view? Is it something people really use anymore?

Patch for tb and sm which removes the UI for mailnews.force_charset_override. I'm not convinced the backend should stay either, but let's leave it at least for now. I don't think this UI is any good because (I imagine) all users who change it would be seeing lots and lots of broken mails (at least users outside ascii...) Left is still the per folder UI which someone might still have use for in newsgroups. (also got rid of some tabs in mailnews.js)

Comment on attachment 294938 [details] [diff] [review] proposed fix I agree with this especially on the grounds of not killing the backend - it's still useful in debugging UCS problems.

Many thanks for the fix!

David: pinging for sr. What do you think?

Comment on attachment 294938 [details] [diff] [review] proposed fix yeah, I'm OK with removing this - we can always put it back if people yell...

Checking in mail/components/preferences/fonts.xul; /cvsroot/mozilla/mail/components/preferences/fonts.xul,v <-- fonts.xul new revision: 1.14; previous revision: 1.13 done Checking in mail/locales/en-US/chrome/messenger/preferences/fonts.dtd; /cvsroot/mozilla/mail/locales/en-US/chrome/messenger/preferences/fonts.dtd,v <-- fonts.dtd new revision: 1.9; previous revision: 1.8 done Checking in mailnews/mailnews.js; /cvsroot/mozilla/mailnews/mailnews.js,v <-- mailnews.js new revision: 3.310; previous revision: 3.309 done Checking in mailnews/base/prefs/resources/content/pref-character_encoding.xul; /cvsroot/mozilla/mailnews/base/prefs/resources/content/pref-character_encoding.xul,v <-- pref-character_encoding.xul new revision: 1.2; previous revision: 1.1 done Checking in suite/locales/en-US/chrome/mailnews/pref/pref-character_encoding.dtd; /cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/pref/pref-character_encoding.dtd,v <-- pref-character_encoding.dtd new revision: 1.2; previous revision: 1.1 done ->FIXED