Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for Google Chrome Stable Version - 49.0.2623.87

This is a Non-Regression issue existing from M30 - # - 30.0.1549.0

This issue seems to affect many downstream apps based on electron.

See issue: https://github.com/electron/electron/issues/5266

#3: I'm not sure the issue in the electron is the same or not. This bug states that it happens with Ubuntu 14.04, while your link says it did not happen with 15.10. Maybe better to file a new issue to get appropriate attention.

drott@, do you have any idea if Ubuntu 16.04 LTS can pick thinner fonts?

iamyzc@gmail.com, you only found this on Ubuntu 16.04? 

kojii@, I don't know what changed in Ubuntu 16.04 font configuration, compared to older versions. It's possible that something changed that makes the font look thinner.

iamyzc@gmail.com, can you right click on the affected page elements and go to "Inspect Element", then go to the "Computed" panel next to the styles panel and post here which font is shown at the bottom (and ideally compare that to what FF shows in its used fonts panel)?

#5: Ubuntu 16.04 changes the default CJK fonts to Noto CJK. See https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1468027.

#5: Yes. Because there're no so many font-weights on previous Ubuntu.
And I noticed that if I put lang="zh-CN" in html tag, it all works fine. Without it, the browser automatically shows thin Japanese style CJK characters. 

Deleted: ChromeA.png 50.8 KB

	ChromeA.png 50.8 KB View Download

Deleted: ChromeB.png 50.2 KB

	ChromeB.png 50.2 KB View Download

Deleted: FirefoxA.png 58.4 KB

	FirefoxA.png 58.4 KB View Download

Deleted: FirefoxB.png 50.6 KB

	FirefoxB.png 50.6 KB View Download

Deleted: 5.png 48.6 KB

	5.png 48.6 KB View Download

Deleted: 6.png 55.4 KB

	6.png 55.4 KB View Download

Here is a walk around: http://www.xiangji.me/2016/04/29/solving-cjk-font-rendering-issue-in-chrome-on-ubuntu-16.04/.

The bug report has a missing piece of information. 

Apparently, Ubuntu 16.04 has Noto Sans CJK packaged in super OTC. In super OTC, all 36 instances of Noto Sans CJK OTF (1.  Noto Sans CJK = 4 locale variants * 7 weights = 28 2. Noto Sans CJK Mono = 4 locale variants * 2 weights = 8) are packaged in a single physical file (TTC). 

Somehow, Blink (likely to be Skia) picks up the first font instance (that happens to be Thin) in super OTC instead of one requested. 

This does not happen when TTC files per weight (total 7 TTC files; e.g. NotoSansCJK-Regular.ttc with 4 locale variants for proportional and 4 locale variants for mono) are installed instead of one super OTC (NotoSansCJK.ttc). 

See https://github.com/googlei18n/noto-cjk/issues/65 and https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1575555/comments/13
(about one super OTC vs 7 per-weight OTC). 

+bungeman for Skia's TTC handling. 

re: comment 7 
> And I noticed that if I put lang="zh-CN" in html tag, it all works fine. 
> Without it, the browser automatically shows thin Japanese style CJK characters. 

Wait. The above comment contradicts the original bug report. zh.wikipedia.org does have lang=zh-CN (or zh-Hans) so that it should work fine, but the original bug report says that it does not. 

Without 'lang' tag, Blink does not have any more information (Blink does not use the detected content language to pick a lang-specific font, yet) and picking 'Japanese' font is not surprising. (you can tweak fontconfig to put SC/Hans ahead of Japanese to avoid that). 

However, picking 'Thin' (for font-weight: 400) even in that case (no lang tag) is still an issue. 

Does that issue go away if you replace one superOTC with 7 per-weight TTC (OTC) files? According to  https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1575555/comments/13 , it goes away, which is why I suspect that there might be an issue with handling SuperOTC (with 36 font instances). 

BTW, Chrome-Linux used to have an issue with dealing with more than 2 weights until a few months ago (see  bug 368442  : fixed on April 28 in trunk). So, 'Thin' being used for font-weight: 400 can be a symptom of that (in that case, why it didn't happen with 7 per-weight OTC files cannot be explained, though). 

Given that  bug 368442  was recently fixed, iamyzc@gmail.com, could you try again and report back? 

Interesting, Skia isn't used for fallback on Linux, that goes through WebSandboxSupport::getFallbackFontForCharacter which ends up using gfx::GetFallbackFontForChar (note that this doesn't support full style information). I know of no particular reason for there to be anything wrong with Skia's handling of TTC, but it's possible that something in SkFontConfigInterfaceDirect isn't quite right.

I'll have to put together a reproducing setup to figure out what might be happening.

As implied by comment 11, this issue was originally filed in March, but  issue 368442  wasn't resolved until the end of April, which then would have made it into a stable release some time later. There have also been a few other cleanups since then. As a result, it is quite possible this has been fixed, or is at least quite different now. However, I'm not sure what would have caused this issue at the time.

Note that trusty package fonts-noto-cjk is this single large .ttc (it has not been updated to the multi-file version). After installing it and running 'fc-list -f '%{weight} \t %{style} \t %{file}\n' | grep /usr/share/fonts/opentype/noto/NotoSansCJK.ttc' shows that both 'Regular' and 'DemiLight' were mapped to FC_WEIGHT 80, so when doing a lookup they will appear the same weight when looking for a match.

Installing this font and following the instructions in the original report I have not been able to reproduce the weight issues on M53 stable. On Wikipedia I get sane weights of Noto, though on most other sites I end up with Droid Sans (apparently because they're requesting 'arial' instead of 'sans-serif'. It's possible I'm just missing the issue though. Is it possible for someone who has observed this in the past to put together a setup where this happened and see if it still affects a recent build? If so, be sure to let us know what's in Inspector > Elements > Computed > Rendered Fonts when inspecting an element with the incorrect font.

> fc-list -f '%{weight} \t %{style} \t %{file}\n' | grep > /usr/share/fonts/opentype/noto/NotoSansCJK.ttc' shows that both 'Regular' and 'DemiLight' were mapped to FC_WEIGHT 80, so when doing a lookup they will appear the same weight when looking for a match.

That's a known issue in the old version of fontconfig. It's fixed (almost 2 years ago IIRC) in a newer version of fontconfig. If Ubuntu 16.x still has the old version of fontconfig, it'll be a factor, too. 

The electron issue https://github.com/electron/electron/issues/5266 says

> It looks like fonts-noto-cjk package is updated and the problem is gone.

Can anyone still reproduce? I don't have Ubuntu 16.04 to test on.

Closing as the report says fonts-noto-cjk package was updated, and no further feedback. Please add comments if anyone can still see this issue.