Reported internally in b/64850414 .
Arguably, this issue can be considered 'Work As Intended'. Moreover, sequences affected by this bug would not show up in regular text (they'd only show up in text concocted to test or spoof or something interesting). So, this is not a high priority issue.
How to reproduce:
A.
Have a web page with "base + combining mark" sequences that are not likely to be supported.
e.g. U+AC00 + U+0305 "가̅"
B.
1. Open in Chrome http://osagelanguagetools.appspot.com/OsageFonts/?utext=%F0%90%93%88%F0%90%92%B0%CD%98%20%F0%90%92%B9%F0%90%92%B7%20%F0%90%93%8D%F0%90%92%B2%F0%90%93%87%F0%90%92%B7&osageText=
2. Enter U+0305 (Combining Overline) after the last character in the text field.
Actual:
1. Both base character and combining mark are turned into tofus
2. Or the base character is turned into tofu while a free standing combining mark without a dotted circle is shown.
What's expected:
There's no clear-cut answer to this situation, especially considering that the script extension of U+0305 is still Common. Perhaps, it'd better be tightened to Latin-like (LGC + a few other scripts).
If 'base + combining mark' is "invalid" ('definition of invalid' TBD), we may as well just show 'base' character (e.g. Korean Hangul, CJK ideograph) intact followed by a combining mark (e.g. U+0305) with a dotted circle.
In case of Firefox on Linux, U+0305 is attached to the base character (Hangul, Han, you name it) , which we can also consider doing, but my preference is in the previous paragraph (especially in light of potential spoofing attempts in domain names with Firefox-like-behavior).
Comment 1 by js...@chromium.org
, Sep 21 2017