Since the encoding used for outgoing email should gravitate towards UTF-8 when in doubt and the fall back encoding used for legacy Web content should gravitate towards windows-1252 when in doubt, the two should be decoupled. The pushback against bug 862292 suggests that going UTF-8-only right away isn't going to fly. Hence, this bug as an earlier step. I worry that this decoupling needs to happen before bug 910192 can land.
If we keep the pref around for email, we could still land the patch that deduces the encoding from locale for the HTML parser, no? Or does email go through the same pipeline somehow?
We have mailnews.view_default_charset and mailnews.send_default_charset already which are independent from the intl.charset.default settings used for the browser. Can you be more specific what you are referring to as being the problem here?
(In reply to rsx11m from comment #2) > We have mailnews.view_default_charset and mailnews.send_default_charset > already which are independent from the intl.charset.default settings used > for the browser. Excellent. Thank you. > Can you be more specific what you are referring to as being > the problem here? I was confused and looking for the wrong thing. Sorry.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.