Bug 943732 added labelsencodings.properties in order to do alias resolution. However the correct way to do this is to use a TextDecoder, which automatically does alias resolution. http://developer.mozilla.org/docs/Web/API/TextDecoder

Except TextDecoder lowercases its encoding, and CharsetMenu.jsm expects to see preserved case... although it would be possible to make CharsetMenu.update case insensitive, if that would be acceptable?

Well, to expand on that, the easy way would be to make all of the charsets in CharsetMenu.jsm lower case, and lowercase the parameter to CharsetMenu.update so that it matches, but I could alternatively maintain two attributes on each menuitem, one in correct case and one in lower case.

> http://developer.mozilla.org/docs/Web/API/TextDecoder See http://hg.mozilla.org/comm-central/rev/7f010544c325#l1.12

(In reply to neil@parkwaycc.co.uk from comment #2) > Well, to expand on that, the easy way would be to make all of the charsets > in CharsetMenu.jsm lower case, and lowercase the parameter to > CharsetMenu.update so that it matches, but I could alternatively maintain > two attributes on each menuitem, one in correct case and one in lower case. Let's not go there. Sorry about mentioning TextDecoder. I forgot it doesn't return in Gecko-canonical case. Why aren't the inputs Gecko-canonical names to begin with? I.e. why do you need to do alias resolution at all in this code? In the browser case, the input is already a Gecko-canonical encoding name. Why not in the editor and email case? Anyway, the scriptable way to get a Gecko-canonical name from a random-case alias *in c-c* is nsICharsetConverterManager::getCharsetAlias() (being removed from m-c; in m-c there will be no scriptable way to do it). (In reply to Philip Chee from comment #3) > > http://developer.mozilla.org/docs/Web/API/TextDecoder > > See http://hg.mozilla.org/comm-central/rev/7f010544c325#l1.12 AFAICT, that code is wrong, because there's nothing in the bowels of gMsgCompose to normalize the charset to a Gecko-canonical name. And this answers my question above about why the name isn't Gecko-canonical in the first place. If you don't resolve encoding labels into Gecko-canonical names as close to the input boundary as feasible, you are going to have a bad time. In my opinion, whatever code extracts the encoding label from MIME should resolve it to a Gecko-canonical name ASAP and then all this code should be able to work with Gecko-canonical names.

(In reply to Henri Sivonen (:hsivonen) from comment #4) > Anyway, the scriptable way to get a Gecko-canonical name from a random-case > alias *in c-c* is nsICharsetConverterManager::getCharsetAlias() (being > removed from m-c; in m-c there will be no scriptable way to do it). Except that one doesn't handle UTF-7. It looks like we don't have a centralized email-oriented way to resolve a label to a Gecko-canonical encoding name! What we have are: 1) (C++ only) mozilla::dom:EncodingUtils::FindEncodingForLabel() : Resolve a Web-oriented label into a Gecko-canonical encoding so that "replacement" is a possible outcome. 2) (Soon to be added C++ only) mozilla::dom:EncodingUtils::FindEncodingForLabelNoReplacement() : Like #1 above except labels that resolve to "replacement" are treated as unknown. 3) (Script only): new TextDecoder(label).encoding: Like #2 above except the return value is in lower case. 4) (c-c C++ and script): nsICharsetConverterManager::getCharsetAlias() : Resolve an email-oriented label into a Gecko-canonical encoding, except UTF-7 is treated as unknown. 5) (c-c C++ only): nsCharsetAlias::GetPreferredInternal() : Resolve a label into a Gecko-canonical encoding, including protocol-internal encodings. Probably always a bug to use. After bug 943268 lands, we should probably change #4 to support UTF-7 to make it the right API to use for email label-to-encoding resolution.