1255242 - Take secondary locales into account for glyph selection, especially in the context of Han Unification disambiguation

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect, P3)

Description

[Yohei Yukawa]

Steps to reproduce the issue:
1. Download and flash Android N developer preview NPC56P into Nexus 6P (this is not device specific though) with system locale en-US.
   http://developer.android.com/preview/download.html
2. Enable Google Japanese Input in the system settings (or install whatever Japanese IME you want to use).
3. Install Firefox for Android nightly 48.0a1 (2016-03-09) into Android N developer preview NPC56P.
4. Launch Firefox nightly, go to "data:text/html,<textarea>"
5. Type "忍者" on the textarea.
6. In the system settings, add Japanese as the secondary language.

Expected behavior:
"忍" is rendered with a Japanese glyph after step 6.

Actual behavior:
"忍" is rendered with a Chinese glyph after step 6.

Chromium bug:
http://crbug.com/593511

Additional information:
In Android N, we are working hard to enable users to specify more than one system languages, which will be exposed to applications as an ordered list of Locales.
http://developer.android.com/preview/features/multilingual-support.html

I'm not familiar with how (system) locale change event has been handled in Gecko, but seems that you can call newConfig.getLocales() instead of newConfig.locale in the following place to get the full list of system languages that the user specified.
http://hg.mozilla.org/mozilla-central/file/93156962855d/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#l2206

It would be great if secondary locales are taken into account for glyph selection in Firefox.

Thanks!

Comment 1

[Yohei Yukawa]

Attachment: Expected behavior

This is how built in EditText works.

Comment 2

[Yohei Yukawa]

Attachment: Actual behavior

This is how Firefox for Android nightly 48.0a1 (2016-03-09) behaves.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't know who are working in gfx for Android, though...

In the old thebes, we checked system locale in same situation on Windows. However, I don't find the code in current thebes. So, I'm not sure which push log tells us who is active contributor for here.

Comment 4

[Makoto Kato [:m_kato]]

We changes fonts by language of HTML instead of input source.  So If lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Makoto Kato [:m_kato] from comment #4)
> We changes fonts by language of HTML instead of input source.  So If
> lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.

How about the language information isn't available or non-CJK but the contents have Kanji characters?

E.g., data:text/html,<foo>漢字</foo> or data:text/html,<foo lang="en-US">漢字</foo>.

Comment 6

[Yohei Yukawa]

Just FYI, I've uploaded screenrecords here too in case you can watch these movies more easily there.
https://drive.google.com/open?id=0ByZK1hhvVhpVTEt1ZVA0VEw3TFU

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #5)
> How about the language information isn't available or non-CJK but the
> contents have Kanji characters?
> 
> E.g., data:text/html,<foo>漢字</foo> or data:text/html,<foo
> lang="en-US">漢字</foo>.

Yeah, that's the problem, and my understanding is that we would eventually need multi-level fallback rules, e.g. en-US > ja-JP > zh-TW, for each context.

As for web browsers, I think it makes sense to put the highest priority on lang attribute, but when it is not sufficient to disambiguate something, it would be great if the browser can treat the system locales as fallback languages.

https://drive.google.com/open?id=0ByZK1hhvVhpVWlJNbFF5emZscE0 is an example where the order of secondary languages matters.

Comment 7

[Makoto Kato [:m_kato]]

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #5)
> (In reply to Makoto Kato [:m_kato] from comment #4)
> > We changes fonts by language of HTML instead of input source.  So If
> > lang="ja", it uses Japanese.  If lang="zh-TW", is uses Traditional Chinese.
> 
> How about the language information isn't available or non-CJK but the
> contents have Kanji characters?

Application locale.  But Android implementation of nsILocale is pretty broken because it doesn't use Java code.  So if locale is changed, Gecko for Android doesn't know it

Comment 8

[Makoto Kato [:m_kato]]

gfxPlatformFontList generates font list per locale data.

Comment 9

[Makoto Kato [:m_kato]]

This is already resolved by bug 1434805. Closing. I have verified on Fenix 80.