Please triage.

+behdad +drott, just FYI

Probably related with issue 672383, which I'm still unable to reproduce, but this one I can reproduce on my Pixel C. Strangely, on Pixel C, not only strange U+300C rendering but also Chrome picks Chinese font when I have "en-us; ja-jp" in my lang setting.

This does not reproduce on my SONY or Samsung, both running M with Japanese settings. 

So probably Chinese rendering is incorrect. My Pixel C with "en-us; ja-jp" should use Japanese font, that should be another bug.

I guess I'd set SONY/Samsung devices to Chinese to narrow this down further.

Created a simple test page:
http://output.jsbin.com/nofeqim
Blink uses Japanese fonts if lang is "en-us; ja-jp" for this test on my Pixel C.

I haven't figured out what in the listed page <http://anond.hatelabo.jp/20170323162129> causes Blink to choose Chinese fonts.

It took me quite a while to setup USB driver for my Windows box, and when I finally succeeded, it no longer reproduces. Sigh. Pixel C had security updates and rebooted while I was fighting with the USB driver, maybe that was the cause.

Japanese fonts are used to render. Even when I add Simplified Chinese, the reported rendering of U+300C no longer reproduce.

kojii@, what kind of feedback/info do you need?

Is this still reproducible with up-to-date Android and chrome?
Does this occur constantly on the same page?
If you see it, and reboot your device, does it still reproduce?

Sorry for the trouble but this is a bit hard to reproduce now (though I succeeded once), and probably Nexus/pixel-only issue. Appreciate help to make this reproducible.

I saw a similar case on my Linux desktop. Here is a screenshot attached.

"あ「<span></span>い" is broken.
"あ" and "「" are Droid Sans Fallback, and "い" is TakaoPGothic, which is weird.

"い「<span></span>あ" is OK.
"い" and "「" are TakaoPGothic, and "あ" is Droid Sans Fallback.

There seems two problem here:
 1. The font fallback is inconsistent. "あ" and "い" should be rendered with the same font. Plus, the default font was Noto on my setting, which is not used here for some reason.

 2. The text width calculation is broken around "「" when "「" is rendered with Droid Sans Fallback and has a following element boundary.

Deleted: a_-i.png 1017 bytes

	a_-i.png 1017 bytes View Download

Deleted: i_-a.png 1.0 KB

	i_-a.png 1.0 KB View Download

tzik@ and I discussed on this, our guesstimate atm is there are 2 separate issues:
1. "Droid Sans Fallback" is suspicious to cause width-measuring problem.
2. We could not identify why we fallback to "Droid Sans Fallback" only on certain cases. This should never happen on normal text.

While 1 is likely to be the root cause of width problem, 2 is probably more common and worse problem. Even if we can measure correctly, we should use Noto, not Droid Sans Fallback.

Quickly looking at ScriptRunIterator and it looks like it assumes script extensions are in the priority order. I'm not sure how true it is from the spec perspective, but at least for CJK punctuation:
300C          ; Bopo Hang Hani Hira Kana Yiii
http://www.unicode.org/Public/UNIDATA/ScriptExtensions.txt
This is just alphabetical order, so the assumption doesn't stand. If we think the open bracket is Bopomofo, maybe that explains because there's no Noto for Bopomofo.

drott@, I hope to understand the code better to come up with an isolated test case, but if you happened to get some ideas from the description, advice appreciated.

Let's try not to mix issues.

> "あ" and "「" are Droid Sans Fallback, and "い" is TakaoPGothic, which is weird.

> "い" and "「" are TakaoPGothic, and "あ" is Droid Sans Fallback.

The logic for text shaping tries to find a font first. If there is no character/glyph coverage in the font chain, the CSS font-family:, then fallback is invoked, and the shaping code shapes as much as possible with the same font. 

This has actually improved consistency in that it tends to use a font more consistently for a longer parts of the run.

In the example from #9: In the first case, initial fallback lookup is done with あ, shaping forward the 「, then doing another lookup. In the second case, the fallback dynamic is a bit different. The initial い is used to find the falback font, then shaping proceeds as much forward as possible and includes the 「. Then, fallback needs to be invoked again for あ.

I've noticed advance width issues when the font changes after the 「 glyph. I have not investigated those.

> "あ" and "い" should be rendered with the same font. 

I agree, however, this is due to the run getting split up by the inserted <span></span>, see issue 6122. So we currently restart on a new run, and the fallback and shaping logic described as above is invoked. 

> ...ScriptRunIterator...?

Can you explain a bit more how you believe ScriptRunIterator affects this issue in this case? Regarding your comment about script order, I believe there is a comment / FIXME in the code about this. If you want to check your assumption, you can write a quick test case for ScriptRunIterator and verify the script segmentation. Do you think ScriptRunIterator resolves the script for 「 incorrectly to Bopomofo? As mentioned, that could be quickly tested.

Sorry that this is still largely based on speculation, but there are two symptoms we can't explain very well.

1. As I the original case, this doesn't repro on different tab, even on the same PC/URL. tzik@  and I had to keep opening the reproducing tab and use inspector to narrow it down.
2. His PC sets Noto for all font setting, and the page had some font-family including sans-serif. We couldn't figure out why Droid Sans Fallback is ever chosen.

1 is maybe related with some caches, shapecache or something else.

2 makes me wonder maybe we're picking wrong entry from GenericFontFamilySettings, which is keyed by script, but yeah, this is very fragile suspect. I'll try to look at some other code and write small tests to see if I can narrow down this further.

Thank you for the very kind advice.

One correction--GenericFontFamilySettings is keyed by lang attributes, so it was unrelated.

I wish we could come up with a concrete repro, but not succeeding yet.

Reading #11 again but still doesn't make sense, Noto, or even somehow we ended up to chose TakaoPGothic, has glyphs for all these 3 characters. How could restarting a new run pick up "Droid Sans Fallback" when one of the font-family has all glyphs?

> Reading #11 again but still doesn't make sense, Noto, or even somehow we ended up to chose TakaoPGothic, has glyphs for all these 3 characters. How could restarting a new run pick up "Droid Sans Fallback" when one of the font-family has all glyphs?

Probably because none of the fonts is specified as the primary font for the run, and all choosen fonts are selected by fallback. Starting a new run will then trigger a new fallback, but with a different character, so our getFontFallbackForCharacter returns a different one than before. If the source HTML would specify one of the fonts in their CSS, it may look better, but then on Android we can't reliably match by family.

> but with a different character

It's not, that troubles me.

"あ「" will pick "あ" as the hint character. Then on the next run, "い" is the hint character. Well, we forgot to test exactly the same character, sorry, but two Hiragana should not pick different font.

And for both cases, fallback doesn't pick Noto when font-family has sans-serif, but TakaoPGothic and Droid Sans Fallback.

And when we open the URL in a new tab, it picks correct font.

We also found only Hiragana "も" was rendered by Droid Sans Fallback but all other Hiragana are TakaoPGothic (or was that Noto, I don't remember...), only in that tab.

So I started to wonder now as I write this, this is more about shape cache, rather than fallback?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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