Bug 14743 – FE characters draw as white box (Tofu) after MLang's HFONT cache is full

• Status: RESOLVED
• Resolution: FIXED
• Component: Text

related: bug#14601

After using Safari/WebKit for a while, white boxes appeared at the position of
FE chars. This time, is not encoding problem, since some part of FE strings
are drawed correctly.

At that time, langFontLink->MapFont() returns E_INVALID, and 
FE font mapping does not succeeded. It's not for invalid argument.
Even arguments intact, this error may occure.

Today some pages depends on MapFont(), and cousumes mlang's internal cache.
With IDE disassembly pane, MapFont() seems have very small font cache entries,
probably only 16, << if we call MapFont with 2nd argument nonzero. >>
If all of entries occupied once, they seems simply return with error
for every new custom fonts creation after that.
// Applies for mlang.dll, v6.0.2900.2180, deployed with XPSP2.
// By MS DLLDB online, WindowsServer2003 SP's mlang is newer, but not tested.
// Cache entry have internal refcount for each, and
// with ReleaseFont(), cache entry is reused (as documented in MSDN.)

See attached example again, some middle of body is rendered.
It's explicit-specified to 'Lucida Grande' part, 
it's cached previously at the time of drawing UI.

I don't know what to do about this concisely,
or whether we should use MapFont() with specify 0 in argument#2,
or whether we should cache by the MapFont's param rather than MapFont's result,
once suspected at bug#14601.

Created attachment 15657 [details]
Issue reproduction html, filling mlang's cache at one go

Created attachment 15658 [details]
Resulting screenshot.

Created attachment 15659 [details]
Reference, screenshots, with 'hacked' mlang.dll, see comments

Experimental/reference only.
With mlang.dll, 'hacked' as internal cache slots 16 to 128,
resulting is without Tofus (white cubes).

Online reproduction.

1. With google searchbox, search 'アップル' 
2. Find and open http://ja.wikipedia.org/wiki/アップルコンピュータ . 
3. White boxed starts appeared at left, but main contents drawed collectly.
4. Restart safari process.
5. Reopen http://ja.wikipedia.org/wiki/アップルコンピュータ .
6. This time whole texts drawed collectly.

With #3 hacks (to mlang) experimentally, whole drawed OK at Step3.

'アップル': Apple, in Japanese Katakana form.
'アップルコンピュータ': Apple Computer, in Japanese Katakana form.

[Alexey Proskuryakov]

With both beta 3.0.2 and nightly r24441, I'm getting similar, but somewhat different results when opening the attached test case: all characters are displayed as white boxes. Same on ja.wikipedia.org (Roman and Cyrillic characters are displayed correctly).

Maybe that's because I'm using an English version of Windows XP.

[David Kilzer (:ddkilzer)]

<rdar://problem/5356812>

[David Kilzer (:ddkilzer)]

Comment on attachment 15657 [details]
Issue reproduction html, filling mlang's cache at one go

><meta http-equiv="content-type" content="Shift_JIS">

For future reference, this should be:

<meta http-equiv="content-type" content="text/html; charset=Shift_JIS">

However, this only affects loading the file locally (from disk).

[Dave Hyatt]

Fixed in r25611.  Long term we may want to remove MLang completely.