(In reply to José M. Muñoz from comment #25)
There is also support for UTF-7 which might be dropped as some stage.
Perhaps I'm too jaded, but my expectation is that you won't get to drop that one. Especially not if you want to keep Thunderbird capable of reading the user's old already-received emails. :-(
Why is this any different for email?
Web page authoring is often detached from server configuration, so the content and the HTTP headers come from very different places. In contrast, email content and MIME headers are typically generated by the same program.
(In reply to Martin Giger [:freaktechnik] from comment #26)
If it's not explicitly wrongly declared you don't need the feature in the first place. This is only for emails where the declared charset does not match the content charset.
The issue isn't mail displaying, the issue is the composing of messages that contain excerpts or the full content of a wrongly declared message.
If the email displayed correctly, shouldn't Thunderbird always take care of it getting quoted correctly?
Regarding other discussion, yes, the display of mails is always in UTF-8. There is some component somewhere that leads to the charset conversion, however that component evidently understands
_autodetect_all, so it must be using the m-c code, or at least depend on parts of it.
The only place that understands
_autodetect_all is the
nsDocShell::SetCharset. It's too late for email and is going away in bug 1713627.
The options here are:
- Not having the feature at all.
CharsetMenu.jsm, restoring the manual items for ISO-2022-JP, Shift_JIS, and EUC-JP, and removing the detector-related items Automatic and Japanese.
- Doing the work, on c-c side, to propagate a "force autodetection" flag through the MIME code to the point where the MIME code currently decides whether to use the detector (and currently uses it only in the absence of a declared
(In reply to Magnus Melin [:mkmelin] from comment #27)
I don't think Telemetry could help.
FWIW, in the case of Firefox, my inclination to keep some form of encoding override is mainly based on Japanese-context bug reports indicating that people still need it combined with the telemetry that the level of usage in Japan is higher than elsewhere and on a different magnitude compared to my frame of experience. I don't have a good way to judge the specific telemetry number, though.
If you were to add telemetry, I suggest two things for analyzing it:
- Instead of looking at the use count, look at one in how many distinct telemetry submitters used the feature at least once over some period of time (e.g. a month). For a low-usage trouble workaround feature this kind of analysis gives a better idea of how relevant it is for users than a use count.
- It's hard to have intuition of where to draw the line. It would be useful to benchmark the result against the usage of some other peripheral feature that you believe is worth keeping. (On the Firefox side, this analysis is missing, and instead, as noted, I'm going by the bug reports being indicative.)
For Firefox, the most recent numbers that have been cleared for publication are in bug 1702914 comment 14.