New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 778299 link

Starred by 3 users
Status: Untriaged
Owner: ----
Cc:
█ kulshin@chromium.org
█ sc00335...@techmahindra.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Application fonts (like tab fonts) fallback should respect secondary language in settings

Reported by i...@vilic.info, Oct 25 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce the problem:
1. Add English and Chinese to settings.
2. Paste "门" and then "门这" inside the address bar.

What is the expected behavior?
Texts should always be rendered with Chinese fonts.

What went wrong?
Texts (e.g. "门") were firstly rendered with Japanese fonts, then (e.g. "门这") Chinese fonts.

Did this work before? Yes 

Chrome version: 62.0.3202.62  Channel: stable
OS Version: 10.0
Flash Version: 

I believe previously (maybe a year ago?) Chrome still respect system fontlink for font fallbacks.
chrome-font-1.png
2.0 KB View Download
chrome-font-2.png
5.0 KB View Download

Comment 1 by manoranj...@chromium.org, Oct 25 2017

Components: -UI Blink>Fonts
Labels: Needs-Triage-M62

Comment 2 by sc00335...@techmahindra.com, Oct 27 2017

Cc: sc00335...@techmahindra.com
Components: UI>Internationalization
Labels: -Pri-2 hasbisect-per-revision Triaged-ET M-64 Pri-1
Owner: kulshin@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 62.0.3202.62 and on latest canary 64.0.3251.0 using Windows 10 with steps mentioned in comment#0. Issue is not seen in Mac and Linux 

Manual Bisect Info:
===============
Good Build: 53.0.2782.0
Bad Build: 53.0.2784.0

You are probably looking for a change made after 402876 (known good), but no later than 402880 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/a223560fd493a9f25d23a33bd624328b6eec854a..0f202ab267491fb469ffcb321560d9f0cfccf825

Review-Url: https://codereview.chromium.org/2054273002

Suspecting same from above changelog.

@kulshin: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks!

Comment 3 by e...@chromium.org, Oct 31 2017

Components: -Blink>Fonts UI>Browser>Omnibox
Chrome UI doesn't use the Blink font stack, changing categories.

Comment 4 by kulshin@chromium.org, Sep 11

Cc: kulshin@chromium.org
Owner: ----
Status: Untriaged (was: Assigned)
Sounds like a fascinating intl bug. I'd like to look into it at some point, but I don't know when that might be, so perhaps someone more active in Chromium should take a crack at it in the meantime.

In the meantime, if anyone can reproduce this bug, please attach your list of installed system fonts since that is likely to be relevant. Run the following from a command line:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" >reg_fonts.txt

Then attach the generated reg_fonts.txt to this bug.

Comment 5 by mpear...@chromium.org, Sep 11

Components: UI>Input>Text
Labels: -Pri-1 Hotlist-Polish Pri-3

Comment 6 by skare@chromium.org, Sep 17

Components: -UI>Browser>Omnibox
Likely ui>input>text component?

Comment 7 by i...@vilic.info, Oct 8 

@kulshin
reg_fonts.txt
42.2 KB View Download

Comment 8 by jbanavatu@chromium.org, Nov 21

Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
**UI Mass Triage**

This issue is still reproducible on latest canary #72.0.3616.0. Adding appropriate labels.
►

Sign in to add a comment