New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 183830 link

Starred by 14 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Aug 2013
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Japanese websites appearing in inappropriate fonts on Android

Reported by, Mar 12 2013

Issue description

Following up from crbug/149542

Users with certain devices are still seeing Japanese websites in inappropriate fonts. 

F-01D|  Android 4.0.3 | Chrome 25.0.1364.123  (2 users) 
101F | Android 4.0.4 | Chrome 25.0.1364.122
Eluga V  P-06D  | Android 4.0.4 | Chrome 25.0.1364.123
ISW11F | Android4.03 | Chrome 25.0.1364.123
F-05D |Android4.03 | Chrome 25.0.1364.123
T-02D | Chrome beta 25.0.1364.122

Users say that "直径" is a good example to see if the font is correct or not. 

Help Forum thread:
Project Member

Comment 1 by, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 2 by, Apr 6 2013

Labels: -Cr-Content-Fonts Cr-Blink-Fonts

Comment 3 by, Apr 23 2013

Additional reports from newer versions: 
KYY04, Chrome 26.0.1410.58, Android 4.0.3 (Gfeedback: report id:798344031) 
Softbank 101F: Chrome beta 27.0.1453.60 and Chrome  26.0.1410.58 : Android 4.0.4 
A few more reports: 

Both devices are 2012 summer models.
- ISW13F
- P-07D  Android 4.0.4, Chrome 26.0.1410.58 and Chrome Beta 27.0.1453.74


Comment 6 by, May 15 2013

I reproduced with the following device: 
F-05, Android 4.0.3 (confirming chrome version) 
Image attached. 

How can we help to diagnose this further? 

1.6 MB View Download

Comment 7 by, May 16 2013

Better screenshot attached, and Chrome version was 26.0.1410.58
314 KB View Download
Status: Available
Relatively recent smartphones (still) sold in Japan are affected by this issue.
Can someone drive this?
Labels: -Type-Bug -Pri-2 Type-Bug-Regression Pri-1
I am seeing this on Galaxy Nexus with Chrome 29.0.1527.3
Seems like a regression as it worked fine on 27 and 28.


186 KB View Download
192 KB View Download
Labels: ReleaseBlock-Stable
Labels: M-29

Comment 12 by, Jun 11 2013

Status: Assigned
can someone tell me which build this starts with? kenji?
Is there a way to do bisects for Android?
I only noticed it yesterday (not 100% sure that it was the first time in 29)
Labels: Needs-Bisect
Works fine on 29.0.1502.0; will try to narrow down from there.
Minimal bisection range:
 - Works fine up to 29.0.1515.0 (WK 537.36 @150885)
 - Broken from 29.0.1517.0 (WK 537.36)

Kareng: can you take it from here? Let me know if you need anything else.
Derek - ideas?  Looks like this is a follow on to crbug/149542
Labels: -Needs-Bisect
There is a skia Roll in the Chromium range: 201835	 Roll Skia DEPS to r9257 (was 9204).


Wild guess on top of a wild assumption (root cause is in Skia) ;)

Maybe something is wrong in the "fontConfig interface for android".
AFAICT, those were the only relevant Skia CLs in the 9257 - 9204 range

I'm out of the office in meetings with partners all week so the earliest I'll be able to address this is next week.  If I had to guess I would say bug is either in the SkFontConfigInterface_android.cpp or in the device specific font files.
Thanks djsollen for the heads up, anyway I can help dissociate which one is the culprit?

reed: can you take a look? Thanks in advance.

Comment 22 by, Jun 20 2013

It is a little tricky for me to know (1) when it is wrong, and (2) when it is right (sorry).

Can someone attach a (very small) page that illustrates the problem, so we can use it to repro (and then test a fix)? Thanks.
I have attached a small test file and a screenshot showing expected / actual with differences highlighted.

FYI: one could compare on Chrome for desktop and Chrome for Android (the JA line is the appropriate style for Japanese content)

Let me know if you need more.

differences highlighted.png
56.0 KB View Download
60 bytes View Download
Reattaching with meta for encoding charset.
150 bytes View Download
Labels: Hotlist-Japan
reed: I hope you were able to reproduce the issue. How does it look? Let me know if you need anything!
So I think I've found the problem and am working on a fix.  We are using the default fallback font DroidSansFallback instead of the custom MTLmr3m.ttf when in the japanese locale.

This is a result of Skia not looking at the current locale set in the device settings and instead using the default fallback chain.

I am wondering how this might relate to a similar issue on other devices before theSkFontConfigInterface_android.cpp change/introduction (original report in #0). Is this DroidSansFallback issue a relatively old thing by any chance?
My CL brings the code back into alignment with how things used to function prior to SkFontConfigInterface_android.cpp.  However, that solution looks at the properties of your Android device to determine the locale and therefore language.  If your device does not have the    think that was not the best and/or right solution.  If you have the "persist.sys.language" property set to "ja" then you will get the standard DroidSansFallback font instead of the custom MTLmr3m font that is used for tha 'ja' locale.

The CL has been commited and will land in Chromium with the next Skia DEPS roll, which will likely be tomorrrow morning.
Looks like this missed the m29 branch point.  It is either going to need to be cherry-picked in or we will need a DEPS roll in the branch for Skia.
This is a fairly evident regression per #9. We should consider bringing the fix in to M29 asap. 
 Issue 254730  has been merged into this issue.
djsollen, thanks for fixing this upstream.
We are eager to see this merge to M29 so that we can confirm that everything is working fine.
Any ETA on this?
kerz@, should we create a branch in Skia at r9712 and add this fix or should we update the m29 DEPS to point at the next time Skia rolled into Chrom (r9768)?

Comment 35 by, Jul 9 2013

Branching then merging the fix needed is the right thing to do.  You can include me on the CL for the DEPS change, and mark requested here when you're ready to merge.
Labels: Merge-Requested
Merged into Skia's chrome/m29_1547 branch as

Comment 37 by, Jul 10 2013

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged
Status: Fixed
This has now been merged into m29
djsollen@: could you tell us if 29.0.1547.23 should have the fix? We are still able to repro and we are getting user feedback about this font issue (since 29 got promoted to beta)... 
On the other hand, the latest dev is apparently fine so crossing fingers that 29 's .23 does not have the fix yet.
kerz@ can probably comment on what build this made it into, but it was very recent (this week) so I would suspect it isn't there.

Comment 42 by, Jul 18 2013

29.0.1547.24 is the first build this is in for 29.
Successfully verified the fix with example from #23 on Galaxy Nexus / JDQ39 / 29.0.1547.32
I am suspecting that the fix on #36 has actually fixed the issue from #9 but not #1. 

I still have some user reports about this font issues, most likely from devices I listed in #1. 
Google Feedback #1092119449 says the issue is not fixed on 29.0.1547.32, device P-06D  
Another report on Play Store from F-05E (tablet) 
He doesn't have a problem in M28 nor Galaxy S3 M29
Google Feedback #884066702
Status: Untriaged
Sorry I'm gonna have to reopen this. We are getting negative user comments on forums and Play Store about the font issue, and I can repro with 101F (originally reported on comment #1). 

This is what happened with this bug: 
- March/April: Only some devices (mainly Fujitsu devices) were having font issues since at least M25 (Original crbug/183830)
- June: Nexus were also having same issues in M29
- July: Issue reported in June for M29 is fixed, but not the original bug 
- August (now): In addition to originally reported devices, I'm seeing increased number of reports from relatively new Sharp phones! 

From yesterday, reported devices are: 
Sharp Aquos phones: SHL21, SH02E, 203SH 
Fujitsu Arrows phones: 201F 
They are all 2012 winter model ~ 2013 spring model

201F is likely to be broken with the same cause as 101F (this bug), but Sharp phones could be broken with completely new reasons. Once we confirm that, we can file a different bug to track it. 

Japanese forum thread for M29 is this:!category-topic/chrome-ja/g9uh9D54wlY
Status: Assigned
Derek / MIke - ideas?  Anything that team in Japan can help collect to diagnose further? 

We are not yet planning a respin on M29 but if we think we need to consider one, can explore it. 
This is getting worse.

User Feedback:
- I've received Forum Alert for 3 times already (I rarely get 1 alert), having 30+ posts from users (I rarely get more than 5 posts for an issue). 
- We now have a Google Feedback cluster (cluster id: 5309099) to track this. Received over 60 reports about this issue alone over the weekend (I normally receive 30 feedback/day for all issues)

- I reproduced on 101F and 201F so far 
- Phones I borrowed from Android team could be different from regular devices and I cannot reproduce issues with phones like SHL21 and SH-02E so far

Affected Device: 
- List of devices only continue to grow. 20+% user reports are from SH-02E (popularly sold phone), 10+% from SHL21 
- Reports are mainly from newer Fujitsu and Sharp devices, but started to see Sony Xperia reports also.
- Full list of devices is in a spreadsheet

There isn't much more I can do from ConOps-side. Please help! 

Labels: -Merge-Merged
Labels: -M-29 M-30
Retargetting m30 stable but with the hope that we can merge the fix in m29.
Labels: -M-30 M-29
Lets leave this on target for M29 before deciding if the change can only land on M30. 
 1. We are trying to reproduce the issue on the Sharp devices by updating them to the latest OS version (to match feedback reports). I will report back with findings. 
 2. I am trying to get hold of a fallback_fonts.xml from an affected device in the hope that it shed some light on the issue.
 3. I also plan to try bisections on newly affected devices.
 4. While combing through the feedback reports, I found  a peculiar "wrong font used" report (#1158251066) which wasn't about Japanese but about Polish. This might be a red herring but can help wonder if the bug is affecting other countries/languages.

Any additional direction would be highly appreciated.

I took a look at the recent reports mentioning Font. Apparently M29 is using some sort of "ComicSans" fonts when rendering latin characters for a significant # of folks...

See this tab of the spreadsheet for sample reports:
The ComicSans bug is likely  bug 274117 
Attached fonts fallback files from Sharp's SHL21 running 4.1.2 (no repro yet as Chrome won't update, probably because Play won't update either...).
If needed I also have the fonts handy.

Falken: very likely indeed, thanks (looks like having the font_fallback xml files helped on that bug so crossing fingers).
3.9 KB Download
3.9 KB Download
Fonts fallback xml file for Fujitsu - 101F (4.0.4, able to repro).
(note: this device does not have a fallback_fonts-ja.xml file)
Re-attaching prefixed files for 101F: fonts fallback, system fonts, list of fonts (MTLmr3m.ttf is a Motoya font typically used for Japanese characters).

609 bytes View Download
2.6 KB Download
2.5 KB Download
Attaching files for Fujitsu 201F (4.1.2; able to repro).characters).
3.9 KB Download
3.9 KB Download
3.1 KB Download
906 bytes View Download
The xml files should help in diagnosis, but knowing what version of OS each phone is running is also important.  Starting in 4.2 support was added for language specific fallback fonts.

I would expect the error to be present on either devices prior to 4.2 or after, but the fact this appears on both is puzzling.
I have a CL that I suspect will fix the issue, but don't have any devices available to me that I can test it on.  I believe the root issue is that prior to Android 4.2 (API Level 17) the OEM could provide an additional xml file that was suffixed with the country code and/or region that file applied to.  This CL adds that logic back for devices prior to 4.2.
I think I wrote the OS version used by each phone for which I shared the xml files. I will take a stab a summarizing the feedback reports for those missing phones.

Also, if you have an apk I am more than happy to help.on QA. 
djsollen: good news, your fix worked for all the newly affected devices I was able to QA!

Fixed for:
 201F     - OS 4.1.2
 SHL21    - OS 4.1.2
 SH-02E   - OS 4.1.2
 SBM200SH - OS 4.1.2

Still not fixed for:
 101F     - OS 4.0.4 (see comment #57 for the fonts and xml files on this device)

I will reach out to our users to check on other devices. 
Meanwhile, can you land you fix and ask for a merge to 29? Thanks!
Labels: Merge-Requested
I suspect that the 101F phone is not a regression, but that it never worked properly when running 4.0.4.

The fix I think is acceptable for m29 is the one I committed into skia.

Comment 65 by, Aug 28 2013

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Pending
Merged into Skia's chrome/m29_1547 branch as

Merged into Skia's chrome/m30_1599 branch as
Project Member

Comment 67 by, Aug 29 2013

Labels: merge-merged-1547
The following revision refers to this bug:

r41313 | | 2013-08-29T15:00:15.341976Z

Labels: -Merge-Pending Merge-Merged
Status: Fixed
the change has landed in m29.
Asking users on forum to download APK file and test it:!topic/chrome-ja/Cix9L6qy-qQ
Hopefully we can identify any devices that the fix isn't working, if there are any. 
Forked the 101F (and a couple of other 4.0.x Android devices) case to  issue 283627 .
We a possibly related issue on linux recently:  issue 272006 .  Linux and Android do not use the same FontConfig code (Android's is in Skia, Linux's is in Blink), but we may be hitting similar troubles here with the (incorrect) assumption in parts of the Blink/Skia code that "Font Family" is a unique identifier.  for  issue 272006  the problem was that Droid Sans is many font files (split into Japanese, Latin, code-point regions) all with the same Family Name.  We lookup the correct font family name (for some japanese character) from FontConfig, pass that through to Skia where it tries to lookup the correct font from that (non-unique) family name (getting back the latin font file) and on linux ended up rendering blank boxs.  The fix:
Looks like you might have been hitting a related issue on Android since you're trying to avoid a case like Droid Sans where a later font file has the same Family Name as an earlier one.
We have many users report this issue again on M38. Shall I file another crbug?

Old thread:!topic/chrome-ja/Cix9L6qy-qQ

New thread:!category-topic/chrome-ja/DengiPKJrs0

Can you please open a new bug?

Comment 74 by, Oct 20 2014

#72-73, as for the M38 issue, please see  Bug 422180 .

Comment 75 by Deleted ...@, Nov 2 2014

I have a probrem with a font.
when i search on google,result context message is inappropriate fonts. 

device SB203SH
os 4.1.2
chrome 38.0.2125.114
277 KB View Download

Sign in to add a comment