1946691 - www.youtube.com - Japanese characters have different font

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Calin Tanase]

Environment:
Operating system: Linux/Windows 10
Firefox version: Firefox 134.0/135/137

Steps to reproduce:

1. Go to https://www.youtube.com/watch?v=l85lZOXbt18
2. Observe the font in the video title.

Expected Behavior:
The font is the same as on Chrome.

Actual Behavior:
The font is different.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/147799

Comment 1

[Calin Tanase]

Attachment: Windows FF vs Chrome.png

Comment 2

[Calin Tanase]

Attachment: Linux FF vs Chrome.png

It is more noticeable on Linux. Some kanji characters as the original reporter stated on the github report, look different. For example "誤", on Firefox (Linux) it looks very similar to "Noto Sans Simplified Chinese" whereas on Chrome (Linux) it looks like "Noto Sans Japanese".

Comment 3

[Tomas]

I reported this on the forum first as this site recommends but I'm guessing it's not monitored?

Copying that info here:

As of today (?), on certain websites, such as Reddit, or on certain elements of some websites, such as text on Google Search's accordion components, Japanese text is suddenly being rendered in Chinese (see images). I have seen reports about this by other users (on Reddit).

This is fixed if ja under font.cjk_pref_fallback_order is moved to the front. However, I found a comment on Bugzilla stating that the font.cjk_pref_fallback_order setting is only honored if Firefox can't determine system font preferences, but about:support lists my locales as ["en-AU","ja-JP"].

This might seem like a trivial issue but the differences in font are extremely noticeable for someone who can read Japanese and makes reading harder.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Jonathan, can you take a look?

Comment 5

[Jonathan Kew [:jfkthame]]

Ah, I see what's happening, at least on Windows -- this is a failure of the OSPreferences service.

As noted in the comment here, we try to use the Windows GlobalizationPreferences APIs to get the list of the user's preferred languages. This works in the parent process, so if Japanese is present in the list, this will take precedence in font fallback searches.

However, in content processes, we fail to get the Globalization Prefs service, and so we fall back to GetUserPreferredUILanguages. But as noted in the comment here, this does not return the full list; in fact, as far as I can see from my testing, it seems to return just the "Windows display language" (an individual single-language setting in the Settings UI, separate from the list of "Preferred languages"), plus an entry for en-US that I suspect may be a hard-coded last resort entry. The other languages I have added to the Preferred Languages list (including Japanese) don't appear at all. And so we end up falling back to the font.cjk_pref_fallback_order pref, as noted in comment 3.

The failure to use GlobalizationPreferences in content processes is related to content-process sandboxing. If I set security.sandbox.content.level to 7 or lower, OSPreferences successfully accesses GlobalizationPreferences, we get the expected list of languages, and the desired fonts. But at level 8 or 9 (the default), the service fails and the problem here arises.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Chris, any thoughts about what we should do here?

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1946691 - Pass system locales from parent to child during content-process startup. r=#platform-i18n-reviewers

This ensures that content processes use the same list of system locales as the parent,
avoiding the issue (on Windows) that sandboxing prevents the content process using
the preferred APIs, and it ends up getting a different (and less useful) list.

(For completeness, we should also modify the Refresh() method to retrieve the system
locales from the parent again, but currently nothing is hooked up to Refresh() on
Windows so it is unimportant for the time being; the user will have to restart the
browser anyhow to pick up changes in the preferred language list.)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e613f4df351a
https://hg.mozilla.org/integration/autoland/rev/1c9634718ce1
Pass system locales from parent to child during content-process startup. r=platform-i18n-reviewers,nordzilla

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/1c9634718ce1