49362 - charset converter cache to use Content-Type charset

Status: VERIFIED INVALID

(MailNews Core :: Internationalization, defect, P3)

Description

[nhottanscp]

This is separated from 47542.
> The cache is done by using the first message headers' charset.
> Since that is usually us-ascii and can be different from the mail 
> body's charset (which is almost always true for non Latin1 cases).
> We need to change to check a charset again for Content-Type charset 
> then reset the cache the converter for the body.

Comment 1

[nhottanscp]

Nominating for nsbeta3, currently Non Latin1 charsets are mostly not cached.

Comment 2

[Jaime Rodriguez, Jr.]

Naoki ~ Please provide more information.

Comment 3

[Jaime Rodriguez, Jr.]

What does this mean in terms of performance impact?

Comment 4

[nhottanscp]

Since charset converters are created for every lines of message body, slower for 
longer messages.
This is basically the same impact as the auto detector creation bug 49411. And 
we create two converters (to and from unicode) per line compare to one auto 
detector per line.

Comment 5

[Jaime Rodriguez, Jr.]

Marking nsbeta3+ per I18N bug triage.

Comment 6

[nhottanscp]

> The cache is done by using the first message headers' charset.
This is correct but if the header's charset is not encoded then the default view 
charset is used. Since I was trying to support the case like a Japanese message 
with non Japanese headers (e.g. e-mail address) with Japanese body, that is 
actually cached when the default charset is set to Japanese.
We only cache for one input charset, so setting a view default to the user's 
native charset make the cache most effective.
So this bug is INVALID, my initial assumption was wrong.

Comment 7

[Katsuhiko Momoi]

Verified as suggested.