It might have something to do with a recent change in Windows fallback font list change. 

Is this something we've been able to reproduce internally? Do we know what version(s) of windows it is affecting?

Prudhvi, Can you please take a look or assign someone from team to repro?

It's mostly Windows 10 according to what I read in an internal mail thread. 

I can't reproduce on Mac. (http://www.youtube.com/?hl=zh-CN) 
 
jainabhishek@: do you see any report from mac? 

IIRC, a recent font fallback change specifies a Chinese font that is installed out of box on English Windows 10. 
Chinese version of Windows 10 may have what Windows 7 and 8 used to have (on all language versions) instead of  that font. 

This is likely a windows only regression, it would be useful to determine whether it only affects Chinese versions of Windows.

Once we have a repro or know the extent of the problem please assign the bug to me.

adding additional issues/info reported by gCon as it's seen on other languages as well:
593258 - Hebrew appears as squares
593262 - Turkish appears as squares
Analysis in progress for Arabic and Sinhalese

On https://www.youtube.com/?hl=zh-TW is fine, too. 

A reduced test case may be (on Traditional or Simplified Chinese Windows 10):

data:text/html;charset=utf-8,<span lang="zh-TW" style="font-family: Roboto, arial, sans-serif;">臺灣</span>
data:text/html;charset=utf-8,<span lang="zh" style="font-family: Roboto, arial, sans-serif;">台湾</span>

I am trying to reproduce the issue will update the bug soon.

bug 593258 (Hebrew appears as squares) and  bug 593262  (Turkish appears as squares) are likely to have the same root cause. Anyway, it's surprising that even Latin (but outside the ASCII) is rendered with Tofu (empty squares). My guess in comment 7 is not likely to hold up given these two additional bugs. 

M49 also includes the font cache/proxy changes, which could potentially interfere, but that seems unlikely since it's under finch and not yet enabled outside canary. If we do get a repro, can we confirm that the repros are not using the field trial ( DirectWriteFontProxy/UseDirectWriteFontProxy/ )? Also would be a good test to find out if enabling the field trial can be used as a workaround.

Please see attached screenshots from users on MAC reporting this issue.

Deleted: Screenshot.jpeg 295 KB

	Screenshot.jpeg 295 KB View Download

Deleted: Screenshot_1.jpeg 312 KB

	Screenshot_1.jpeg 312 KB View Download

I wasn't able to reproduce the bug tried on Windows 10 traditional Chinese with latest Chrome Stable i.e., 49.0.2623.87 Please find the attached screenshots and system font list and Windows Build number in attachment.

Note : Command used to get registry fonts key output "reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" >reg_fonts.txt" 

Deleted: reg_fonts_1511beforeupdates.txt 9.1 KB

reg_fonts_1511beforeupdates.txt 9.1 KB View Download

Deleted: youtube.png 1.1 MB

	youtube.png 1.1 MB View Download

Deleted: Windowsbuildnumber1511.png 276 KB

	Windowsbuildnumber1511.png 276 KB View Download

+momoi: just in case, he has an idea for reproduction. 

pbommana@: can you reproduce   bug 593262  (Turkish)? 

 jainabhishek@ : could you delete the spreadsheet in your bug report? 

I put it up at https://docs.google.com/a/google.com/spreadsheets/d/1fjnnwQFAyPxDUUelvMuGUX6w5SwnrfHyHrCP4KsqZYw/edit?usp=sharing (internal). 

With the attached spreadsheet removed, we can drop 'Restrict-View-Google' so that we can get feedback from the public.

Bug is now public

FYI - might not be the same, but similar report on Japanese chrome user forum:
https://productforums.google.com/forum/#!topic/chrome-ja/5tqwtWvLySg;context-place=forum/chrome-ja

Summary:
Many reports are on windows 10, since M48, and on OneDrive or Outlook web mail.
Only happens on Latin characters and Japanese are okay.
A workaround suggested by someone in the thread is to disable DirectWrite.

I'm not able to reproduce this yet, but by searching on the web, maybe this is related:
> Solution 2 – Reinstall the font
> If you have upgraded to Windows 10 from Windows 7 or Windows 8...
> In most cases it’s Arial or Mingliu.
http://windowsreport.com/font-bugs-windows-10/

I believe the mac reports in #16 are a different root cause, the .nodef glyphs in the Mac screenshot seem to be coming from the respective web fonts, not from a system font that fails to render. I have a couple of updates in  bug 593262 , the Turkish issue.

Got a clean win10 ja and tw, but neither youtube nor case in #10 can repro.

win7tw upgraded to win10tw, but still unable to repro.

 bug 593262  is likely to have a different cause.  If so, I wonder Windows 10 has multiple tiers (professional, family, enterprise etc) with different sets of fonts installed out of box?  

The font list in comment 17 has all the Chinese fonts (Chrome's default font fallback uses), but other tiers of Windows 10 may not have them all. 

re: comment 24: http://windowsreport.com/font-bugs-windows-10/ (solution 2) seems promising (especially because  'MingLiu' (Traditional Chinese font) is affected). 

 For an unknown reason, it seems to affect only a subset of users (kojii@ can't reproduce it). 

BTW, Youtube has 'sans-serif' at the end of its font stack with 'lang=zh-TW' in which case 'Microsoft JhengHei' is used instead of 'MingLiu'.  It might be the case that 'Microsoft JhengHei' is also affected in some cases. Anyway, I filed  bug 593862  to get Chrome to cope better with situations like this. 

We suspect this to be a duplicate of 593262.

Could someone who can repro this bug with the Chinese fonts try launching Chrome with the flag: --force-fieldtrials=DirectWriteFontProxy/UseDirectWriteFontProxy/

That fixes the problem for Turkish, so it would be good to know if it's also fixed for Chinese.

> Based on drott@'s testing, it seems like toggling the proxy does fix this. It
> seems likely that in splitting the code paths you lost some warm-up in the
> caching version that you are still doing on the proxy side. Do you have reason to
> suspect there's something else going on?

For the Turkish case in particular, it seems really weird that it's just one glyph that's failing. If it was font loading, it is likely that the entire font would be missing. It almost sounds like Chrome is trying to use the wrong font - either because it's not finding the font that it really wants, or because the priority for which font to use is messed up.

>> There's also a risk of completely crashing the renderer, in which case it
>> wouldn't render anything.

> What specific risk are you referring to here? Because I'm not aware of anything
> beyond what we have with the cache path.

Nothing specific, but it is a considerably less tested codepath. My main concerns would be for systems where the fonts are in a non-standard configuration (loaded from outside system directory, or something else like that).

I tried reproducing this by switching Chrome's UI language and accept-languages to Simplified Chinese and visiting YouTube, on the same box that has the Turkish reproduction, but to no avail.

drott@, for this issue, most reports came from Traditional Chinese users (MingLiU and Microsoft JhengHei are TC fonts), I believe.

> We suspect this to be a duplicate of 593262.

Has anybody reproduced the bug and found that either turning off DW or using --force-fieldtrials=DirectWriteFontProxy/UseDirectWriteFontProxy/ (with DW ON) resolved this issue? 

If so, this would be indeed a dupe of  bug 593262 . 

#36 - there's multiple anecdotal reports on the internet that disabling direct write can be used as a workaround (we don't want to do that for other reasons though). I haven't heard any confirmation about the field trial flag yet.

Tina found a forum thread on this issue ( https://productforums.google.com/forum/#!topic/youtube/r9XTo3uU5c0 ) and I asked folks there to try all three methods (1. using fontproxy 2. turning off DW 3. reinstalling fonts) and report back. 

In the above forum thread, Simplified Chinese users also reported the same issue and changing the default font from 'Simsun' to 'Microsoft Yahei' [1] solved the problem. So, Simsun (in addiiton to MingLiu) is somehow affected. 

[1] Hmm... The default Hans font (preference) was changed to Microsoft Yahei a while ago. Maybe, the old preference stuck. 

In the same product forum thread, another workaround is mentioned. This issue happens when Chrome's UI language is NOT Chinese (zh-Hant or zh-Hans). Because the default Chinese sans-serif font with lang=zh-* is Microsoft Yahei/JhengHei that do not seem to be affected by 'Win 10 font upgrade anomaly', this does not happen to Chrome running in zh-*. 

-----------
OK I found a solution. Go to setting -> advance setting -> language, then click the tab "language and input setting", click chinese (simplified or tradition), then click the tab "display google chrome in this language"

It will solve the problem but also changed the chrome language, but if you change it back the problem won't come up again. 

----------

Then, it dawned on me that Windows fontfallback code tries Simsun / PMingLiu first before trying newer fonts, 'Microsoft YaHei' and 'Microsoft JhengHei'. 

We can just swap the search order (i.e. putting newer fonts first) and this problem should go away without users doing anything. 

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/fonts/win/FontFallbackWin.cpp&l=197

This will change the default Hans and Hant fallback fonts for non-Chinese Chromes, but the default Hans/Hant fonts for Chinese Chrome users have been Microsoft Yahei/JhengHei for a while (comment 39 #1). So, it should not be an issue and arguably we should have swap the order long before this.  

I'll make 2-line CL. 

Nonetheless, the underlying issue has to be tracked down. 

> Nonetheless, the underlying issue has to be tracked down

Because my 2-liner would not help Turkish with Arial ( bug 593262 )

BTW, perhaps this should lead to a reproduction (if a font is kinda broken as on those with this issue):

https://www.youtube.com/results?search_query=%E4%B8%AD%E5%9C%8B%E4%B9%8B%E6%98%9F&hl=en

Chrome's UI language should be English (and the font preference should be set to OOB values - i.e. sansserif = Arial, standard=Times New Roman, etc). Youtube UI language should also be English (hl=en), but the web page contents should have some Chinese. 

I made a CL ( https://codereview.chromium.org/1784913003/ ) and ran blink trybot only to find that the patch failed. 

It turned out that kojii@ made a virtually identical CL and landed several hours ago: 

https://codereview.chromium.org/1754143002

BTW, I realized that the screenshots in the report (comment 0) are clearly in Traditional Chinese UI (Youtube, Chrome and Windows). In that case, the fallback font for Traditional Chinese should be 'Microsoft Jhenghei' with or without the CL above (unless a user reporting the issue changed her/his font preference to use 'PMingLiu'). Despite that, they still have this issue.

#43: I thought about it too, but I suspect the CL won't solve. We have JhengHei next to MingLiU, so if we failed to find MingLiU, we should render correctly. The problem is likely that it looks like MingLiU exists to our code, but can't render.

The page has lang=zh-tw and sans-serif, so we should be using the default font specified in the setting, and the setting is likely to have MingLiU, so the GenericFontFamilySettings is likely to be used before the system fallback. To fix that, we'd probably have to check the name of the font and replace with something else. Does this sound good direction?

Another thought, if that's the case, the bug should affect pages with "font-family: MingLiu", and such pages should be a lot more.

Do we have contact to the affected users? Could we ask some of them what fonts they have in the settings for sans-serif, and what happens if they change to the different font in the settings?

> We have JhengHei next to MingLiU

Well, in the past, the font presence check behaved in an unexpected manner and failed to try the second one in the list. So, I thought something similar might be going on. 

> The page has lang=zh-tw and sans-serif, so we should be using the default 
> font specified in the setting, and the setting is likely to have MingLiU

The default sans-serif Hant font (zh-TW) is NOT PMingLiu but Microsoft Jhenghei in CHrome (out of box).  See https://code.google.com/p/chromium/codesearch#chromium/src/chrome/app/resources/locale_settings_win.grd&q=Jhenghei&sq=package:chromium&type=cs&l=331

If Blink is not picking up Microsoft Jhenghei (based on lang=zh-tw) before going to the hardcoded fallback font list, it's another regression that needs to be fixed (separate from this bug). 

If that has not regressed, this should not happen with lang=zh-TW. That's why I asked try Youtube in English UI ( hl=en in my url).  

However, the screenshots attached in the bug report shows Youtube in zh-TW UI (and Windows and Chrome's UI lang is also zh-TW). So, there might be indeed a regression in our font selection. That is, the font selection based on 'lang=foo' is not working any more? 

> Do we have contact to the affected users? Could we ask some of them what fonts they 
> have in the settings for sans-serif, and what happens if they change to the 
> different font in the settings?

See my comment 38. I didn't ask them for their font settings, yet. We can. 

atm, possible suspective fixes are:
1. Believe this is dup of the Turkish, takes no action on this one.
2. Believe MingLiu is broken and forcibly replace with something else; i.e., MingLiu-ExtB or JhengHei

Unable to repro for us makes me feel that 1 is not likely. Not hearing problem on other pages feels me that 2 is not likely. Thoughts?

"MingLiu-ExtB" does not cover any regular BMP Chinese characters. As its name implies, it's for CJK Ideograph Extension B (Plane 2). 

And, as I wrote above, it's strange that Microsoft JhengHei is NOT picked up for pages tagged with lang=zh-TW. If it's not picked up, it's a (separate) bug/regression. 


>  pages with "font-family: MingLiu

A surprisingly small number of  Hant pages explicitly specify TC-specific fonts the last time I checked. Well, it's 7~8 years ago, though. Most of them tend to just specify a generic family. 

> "MingLiu-ExtB" does not cover any regular BMP Chinese characters. As its name implies, it's for CJK Ideograph Extension B (Plane 2). 

ah, I didn't know that, thank you. That's strange though, in my English/Japanese win10, they have JhengHei and MingLiu-ExtB, but not MingLiu.

> And, as I wrote above, it's strange that Microsoft JhengHei is NOT picked up for pages tagged with lang=zh-TW. If it's not picked up, it's a (separate) bug/regression. 

Our change only affects to new profiles, if the user creates their profile before we change, they should keep MingLiu or whatever fonts they picked, no?

>>  pages with "font-family: MingLiu
>
> A surprisingly small number of  Hant pages explicitly specify TC-specific fonts the last time I checked. Well, it's 7~8 years ago, though. Most of them tend to just specify a generic family. 

understood, thanks for the info.

Adding webfont expert as youtube has Roboto as the primary font, and it's webfont.

Updated speculations:
1. Believe this is dup of the Turkish, takes no action on this one.
2. Believe MingLiu is broken and forcibly replace with something else; probably JhengHei
3. Somehow we use Roboto, the web font, to render Chinese characters.

Hard to tell if the Latin characters in the screenshots are Roboto or Arial.

 bug 593262  is rolling, hope it fixes ;)

> ah, I didn't know that, thank you. That's strange though, in my English/Japanese
> win10, they have JhengHei and MingLiu-ExtB, but not MingLiu.

That's why I talked about the list of fonts installed by default (out of box). Apparently Microsoft recently changed their policy of what fonts to make available out of box on Windows. In Windows 7 (and perhaps 8), all the fonts are installed out of box regardless of the UI language of Windows.

Apparently on Windows 10, only 'core fonts' (this is my terminology. I don't know what name is used by MS to refer to this set of fonts) are available out of box. This set does NOT include "old" fonts (from Windows 9x/2k/XP days) for some languages. For instance, on English Windows, old Traditional Chinese fonts such as PMingLiu/MingLiu (they're in TTC and the only difference between them is that PMingLiu has proportional ASCII glyphs while MingLiu has fixed-width ASCII glyphs) are not installed out of box. 

Users can still install old fonts (like MingLiu/PMingLiu).  

Anyway, that's why I suggested swapping the search order (in addition to the fact that in the past in some situations, the second or third fonts in the hardcoded fallback list for a given script was not picked up even when the first font in the hardcoded fallback list is not present on a given machine). 

Moreover, this last resort per-script fallback list order should NOT matter for pages with an explicit language tag (e.g. lang=zh-TW) because per-script user preference font (for zh-TW, Hant, it's Microsoft JhengHei) should be picked up before resorting to the hard-coded fallback list.  Youtube does have an explicit languge tag (lang=zh-TW for TC UI) and we still have this issue. That can mean

1) somehow there's a regression in our font fallback in that we do NOT use per-{script, css generic} font preference EVEN WHEN a page is explicitly language tagged. (that's why I brought up this question in yesterdays' group chat. That issue is relevant to this bug.). For zh-TW, it'd be Microsoft JhengHei. 

2) There's NO regression like #1, but even Microsoft JhengHei has an issue (as is the case for (P)MingLiU and Arial ) with DW.  What a user found (I quoted in comment 40) makes it impossible for this to be the case at least for that particular user, though. 

Anyway, if this is the case, I suspect that there are 3 things to try:

  a. Let users reinstall all the potentially affected fonts as outlined in http://windowsreport.com/font-bugs-windows-10/

  b. Disable DW (this one we do NOT want even though it's proven to work; we do not want to go back to GDI !!)

  c. Turn on DW fontproxy (as we're experimenting now for  bug 593262 ). 

In https://productforums.google.com/d/msg/youtube/r9XTo3uU5c0/cvwbJj42IwAJ, I asked users with these issues to try them, but no reply so far. Apparently, they're happy with yet another work around of changing the default font to Microsoft JhengHei (see comment 40). 

Were we able to determine whether this was related to  bug 593262 ?

#56: I strongly suspect it's related, given that I haven't heard any more complaints about this after we rolled out the font proxy field trial. However, I haven't heard definitive confirmation from anyone who was able to repro the bug in Chinese. If anyone has a repro of the Chinese problem, it would be good to get definitive confirmation. If you could also share your font cache file that might be useful for future diagnostics as well.

Unable to reproduce the issue on windows 10 using chrome version 49.0.2623.87.
Able to see the Chinese font rendered fine without any issues.
Please find the attached screen shot for the same.

Thanks,

Deleted: 591340.png 50.7 KB

	591340.png 50.7 KB View Download

Issue 593258 has been merged into this issue.

Per C#57, Could anyone confirm if they are still seeing such issues post font proxy trial roll out on the latest stable(49.0.2623.87).

We are not getting any reports from Chinese, turkish or hebrew using users about fonts being replaced by squares on M49.

+Nataliya

Thanks for the updates everyone. Given the lack of reports and the fact that we believe this to be due to the same root cause as 593262 I'll go ahead and mark this as closed.

Please comment and reopen if we start getting reports for this again.

Thanks!