1002468 - Remove labelsencodings.properties

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[[e-mail]]

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

Comment 1

[[e-mail]]

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?

Comment 2

[[e-mail]]

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.

Comment 3

[Philip Chee]

> http://developer.mozilla.org/docs/Web/API/TextDecoder

See http://hg.mozilla.org/comm-central/rev/7f010544c325#l1.12

Comment 4

[Henri Sivonen (:hsivonen)]

(In reply to [e-mail] 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.

Comment 5

[Henri Sivonen (:hsivonen)]

(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.