1008832 - Make the isInternal mode of nsIScriptableUConv more backwards compatible

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Henri Sivonen (:hsivonen)]

See bug 943268 comment 45.

Comment 1

[Henri Sivonen (:hsivonen)]

Attachment: Try munging the label into something that works

I intentionally didn't make this work with T.61-8bit (mixed-case canonical name), since I expect Thunderbird not to keep that one.

Comment 2

[Masatoshi Kimura [:emk]]

Comment on attachment 8420836 [details] [diff] [review]
Try munging the label into something that works

We should not allow "replacement" as a valid label.

Comment 3

[Henri Sivonen (:hsivonen)]

Actually, there are more email encoding alias in addition to ISO-2022-CN-EXT. Maybe the ISO-2022-CN-EXT hack here should go away and the API doc should just tell email callers to do their alias resolution using nsCharsetAlias first.

Comment 4

[Henri Sivonen (:hsivonen)]

Attachment: Try munging the label into something that works, v2

(In reply to Masatoshi Kimura [:emk] from comment #2)
> Comment on attachment 8420836 [details] [diff] [review]
> Try munging the label into something that works
> 
> We should not allow "replacement" as a valid label.

OK.

Comment 5

[Masatoshi Kimura [:emk]]

(In reply to Henri Sivonen (:hsivonen) from comment #3)
> Actually, there are more email encoding alias in addition to
> ISO-2022-CN-EXT. Maybe the ISO-2022-CN-EXT hack here should go away and the
> API doc should just tell email callers to do their alias resolution using
> nsCharsetAlias first.

nsCharsetAlias is not scriptable (not even an XPCOM interface). Perhaps we should add a hook in nsScriptableUnicodeConverter::InitConverter() so that c-c can add their alias resolution?
If only C++ callers need those encodings, they can just use nsCharsetConverterManager directly.

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to Masatoshi Kimura [:emk] from comment #5)
> (In reply to Henri Sivonen (:hsivonen) from comment #3)
> > Actually, there are more email encoding alias in addition to
> > ISO-2022-CN-EXT. Maybe the ISO-2022-CN-EXT hack here should go away and the
> > API doc should just tell email callers to do their alias resolution using
> > nsCharsetAlias first.
> 
> nsCharsetAlias is not scriptable (not even an XPCOM interface).

nsICharsetConverterManager::getCharsetAlias is scriptable. How about I point to that in the comment?

(From an email perspective, that one fails for UTF-7, because this stuff hasn't been designed right from the get-go... However, now that nsICharsetConverterManager is going to be c-c only, they could un-ban UTF-7 in that method.)

> Perhaps we
> should add a hook in nsScriptableUnicodeConverter::InitConverter() so that
> c-c can add their alias resolution?

Possibly, but I won't have the time to do that today and c-c is still closed due to being blocked on this. So I suggest we land this patch (with the comment pointing to nsICharsetConverterManager::getCharsetAlias) to unblock c-c on the worst issue and then let c-c devs add a pluggability point here as a follow up once their tree isn't totally burning anymore and they still consider a pluggability point necessary.

Comment 7

[Masatoshi Kimura [:emk]]

Comment on attachment 8420857 [details] [diff] [review]
Try munging the label into something that works, v2

OK, let's unburn c-c before further discussion.

Comment 8

[Henri Sivonen (:hsivonen)]

Thanks. Landed with a mention of nsICharsetConverterManager::getCharsetAlias() in the comment.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ff77189e55df

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ff77189e55df