Attached wrong screenshot attaching the correct one.

"Google", "Nexus" and numbers are rendered in regular weight in the main
article, and in the footer, for example, "Google" is rendered in regular weight,
while only "s" in "Cast" is in regular weight.

Just guessing that glyphs already used are cached and reused ignoring weight.
  

Deleted: Screenshot_20160613-143145.png 357 KB

	Screenshot_20160613-143145.png 357 KB View Download

I haven't seen this on English sites so far, but quite reproducible on Japanese sites.

Attaching another example (taken from
http://www.4gamer.net/games/304/G030407/20160613034/ )

Deleted: Screenshot_20160613-145728.png 411 KB

	Screenshot_20160613-145728.png 411 KB View Download

I don't see this reproducing on stable (M51), marking this as regression in M-52.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

this has been happening since M52. and yes, it doesn't seem to happen on non-japanese sites.
here is another site to reproduce: http://blog.ushitora.jp/

just played with devtools, changing the value of lang from "ja" to "en" makes all ascii characters bold. changing it to "fr" or "" makes the same (all ascii chars gone bold); however, changing it to "zh" or "ko" has no effect. (sceenshots attached)

and more importantly, hiragana, katakana, and kanji cannot be bold at all.

Deleted: Screen Shot 2016-06-16 at 21.01.57.png 205 KB

	Screen Shot 2016-06-16 at 21.01.57.png 205 KB View Download

Deleted: Screen Shot 2016-06-16 at 21.02.17.png 198 KB

	Screen Shot 2016-06-16 at 21.02.17.png 198 KB View Download

Deleted: Screen Shot 2016-06-16 at 21.02.31.png 196 KB

	Screen Shot 2016-06-16 at 21.02.31.png 196 KB View Download

Could you add "text-rendering: optimizeLegibility;" as a style for one of the larger divs and see if the issue is gone? I am suspecting that is a regression in the simple text path on Android. I just discussed the bug this morning with kochi@, and it might be that it's fixed if we can move to the complex font path by default on Android.

kochi@ told me that this reproduced in an English site, looked like if a character appear in bold first in the page, the same non-bold character use the bold font.

kochi@, have a URL?

As I commented in #2, I haven't seen this on English-only sites so far :)

@drott I tested with inspector, and confirmed that adding "text-rendering: optimizeLegibility" fixed the mixed bolding issue.

See the screenshots, for how "text-rendering: optimizeLegibility" fixed the rendering.

Deleted: ScreenShot 2016-06-17 9.07.37.png 1.1 MB

	ScreenShot 2016-06-17 9.07.37.png 1.1 MB View Download

Deleted: ScreenShot 2016-06-17 9.07.51.png 1.2 MB

	ScreenShot 2016-06-17 9.07.51.png 1.2 MB View Download

I'm not certain this is the same bug, but on Android (m52), setting:

document.body.innerHTML = "<p dir='ltr'>Te<b>stقغع</b>خلس te<b>stは</b>ゆ</p>"

Causes the Arabic portion to be displayed fine, however the Japanese portion should show the first character in bold, and doesn't. Replacing <b> with <i> shows that italics are displayed ok. Similarly, making it a span with font-weight set to something only affects the latin characters.

Version: 52.0.2743.49 (beta)
OS: Android 6.0.1; Samsung Galaxy S7 (MMB29K)

Similar problem happens for KR contents, too. In the mixed contents, only numbers get bold. Here are some links.

http://blog.naver.com/g901217/220741126859
http://mmya.auction.co.kr/item/vip#/B338082666
http://www3.nhk.or.jp/news/html/20160620/k10010562801000.html

Deleted: Screenshot_20160701-090554.png 207 KB

	Screenshot_20160701-090554.png 207 KB View Download

Deleted: Screenshot_20160701-090841.png 151 KB

	Screenshot_20160701-090841.png 151 KB View Download

Deleted: Screenshot_20160701-091418.png 549 KB

	Screenshot_20160701-091418.png 549 KB View Download

We got loads of feedback about this in M52, let's get it fixed for M53 please - raising to Pri-1, marking as RB-Stable.

Assigning to drott@ given the suggestions made in c#7, but please re-assign if someone else is more appropriate.

Did a bisect and found this,
Good build: 52.0.2719.2
bad build: 52.0.2720.0
Change list: https://chromium.googlesource.com/chromium/src/+log/52.0.2719.0..52.0.2720.0?pretty=fuller&n=10000
There are a bunch of fonts related CLs that went into this build.

I can't reproduce the mixed bolding effect on 52.0.2743.98, tested with URLs, from above:
http://www.4gamer.net/games/304/G030407/20160613034/
http://www.4gamer.net/games/342/G034227/20160616132/
http://getnews.jp/archives/1474996

kochi@, have you seen the mixed bolding again?

However there is _no bolding_ at all on the headline and in the green links at the bottom of the getnews site. This is most likely because synthetic bold regressed after crrev.com/f24ce736e38fa9b1 (parts of the changelist in comment 16)

Looking at the CL, https://codereview.chromium.org/2225723003 is a quick fix proposal which fixes synthetic bolding in this case and the pages 1-3 mentioned above look okay with that in terms of bolding. I verified this on 52.0.2743.98 plus this CL.

Assigning to thomasanderson@chromium.org who's the author of crrev.com/f24ce736e38fa9b1. Could you please add a test case for synthetic bolding, and help with verification and merging?

More generally speaking, for a bit of background: After we identified the mixed bolding to be an issue in the simple font path, as shown by kochi@'s comment #11, I considered this lower priority since we are aiming to switch to the complex text code path by default in M53. While I had observed the mixed bolding issue initially after kochi's report, I don't know what has changed so that the mixed bolding does not occur anymore.

Re comment17, my Nexus5X has M51 stable and M53 beta, and on M53 beta, the problem is
reproducing.
Even with getnews.jp page, I saw mixed bold & regular (see attached screenshot).
The exact version is 53.0.2785.49.

Could you check the URL after changing the UI locale to Japanese?

Deleted: Screenshot_20160808-233425.png 319 KB

	Screenshot_20160808-233425.png 319 KB View Download

Thanks, bashi@. 

Okay, I was on the wrong Android version, on shamu (Nexus 6) 6.0.1 confirming that I can see mixed bolding with beta 53, similar to your screenshot, single characters bold, some others not.

I see mixed bold, but only on a word level with 54 ToT (which is on complex text by default).

With 54 ToT and my suggested fix applied, it looks okay.

With 54, modified to be simple text by default, and the fix applied, it looks okay, too.

Another observation: The Japanese glyphs in the headline should be bold, as they do in my modified version, but they don't appear bold in M53.

drott@'s fix in #17 looks like the proper fix.

+jshin@
Do you have plans to add the layout tests as described in https://codereview.chromium.org/1912013002/#msg62

Not sure why commit bot didn't pick it up, but the CL in #17 has landed in
https://codereview.chromium.org/2222153002/
Will merge into M53 tomorrow, and add a layout test

M53 merge land https://codereview.chromium.org/2229913002/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3973fe39eb894a1775f742c42cfea4c16346c7bb

commit 3973fe39eb894a1775f742c42cfea4c16346c7bb
Author: thomasanderson <thomasanderson@google.com>
Date: Tue Aug 09 19:35:21 2016

Fix synthetic bolding of system fonts on Linux/Android

Merge of https://crrev.com/6da9f6f5e38dfd98ac40055c441aa3c9fe768877

NOTRY=true
NOPRESUBMIT=true
BUG= 619464 

Review-Url: https://codereview.chromium.org/2229913002
Cr-Commit-Position: refs/branch-heads/2785@{#543}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/3973fe39eb894a1775f742c42cfea4c16346c7bb/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp

Verified fix in M53 - 53.0.2785.57. Ex. Japanese font on yahoo.co.jp is now shown in 'Bold'.
Thanks!

 Issue 638550  has been merged into this issue.

Marking as fixed per c#28.

> Will merge into M53 tomorrow, and add a layout test

Thanks for landing and merging, any news on the layout test? It would be good if we could lock this down with a regression test. Thanks.