JhengHei improperly assigned as zh-tw default font, ignoring user settings and default behavior
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: a29988122, Assigned: jfkthame)
References
Details
(Keywords: regression)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 Steps to reproduce: As of FF64, due to this change(narrowed down by mozregression): https://bugzilla.mozilla.org/show_bug.cgi?id=1394709 It triggered an unintended behavior which is *somehow* irrelevant to this commit. That is - the default font is forced no matter the customized font settings. Actual results: https://imgur.com/a/b3s4q16 I'm not a front-end designer, so I have 0 ability to identify certain font type. The behavior is that it "seems like" everything now defaults to JhengHei. Revert to FF63 solved this issue. Expected results: As of now, latest zh-tw chrome with default font settings has the same font behavior as FF63.(Not really like what have been discussed in the problematic commit discussed) That's the way to go.
The previous bug description post: https://bugzilla.mozilla.org/show_bug.cgi?id=1514112#c2
Updated•5 years ago
|
Comment 2•5 years ago
|
||
m_kato and jfkthame are better people to look into this.
Comment 3•5 years ago
|
||
Preference cannot show font list, so it only shows 1st entry of font.name-list.sans-serif.zh-TW. But we will remove Arial entry by bug 1475148. Also, you want to back to old settings, you can modify font.name-list.sans-serif.zh-TW by about:config.
>(In reply to Makoto Kato [:m_kato] from comment #3) > Preference cannot show font list, so it only shows 1st entry of > font.name-list.sans-serif.zh-TW. But we will remove Arial entry by bug > 1475148. > > Also, you want to back to old settings, you can modify > font.name-list.sans-serif.zh-TW by about:config. I don't really get the browser font choosing behavior, even after 30 min of research It's even more complex than the cryptography paper I'm writing. Jokes aside, I found the font choosing of Chrome(default settings, of course) stay inline with other zh-tw windows 10 fonts, while the "new" font choosing of FF64 is less than ideal. Is that intended? Why fix something that's not broken, unless this is a more a stylistic choice and you'd like to force it to your users - I really really saw a relatively large amount of outrage of this FF64 font changing in the zh-tw community. Maybe you can ask your fellow in Taipei office about this. *** To sum up the intent of this ticket: 1. Rather than about:config bypass, you cannot change the fonts in the UI option no matter how hard you try. I guess this is what has been addressed in Bug 1475148? 2. If you really want to change the main zh-tw default display font to jhenghei, why not asking your user before change? As a open source spirit doer, I hate seeing the market share of Firefox keep dropping.
Comment 5•5 years ago
|
||
Well, I would like to clear this issue. Do you say that you cannot change default zh-TW sans-serif font by about:preferences? Actually, default shows "Default (Arial)" for zh-TW, but I think that you can change it to any font that you want. After fixing bug 1475148, it will be shown as JhengHei. Also, before adding JhengHei to our config, font.name.sans-serif.zh-TW list might be invalid since Windows 10 mightn't install old zh-TW fonts. (example, old font isn't installed on English Windows, so it causes performance issue such as bug 1496790).
カトさん: 怒りに任せてバグのリポートに誤解を招いて申し訳ありません。 改めて正式のフォーマットでもう一度試します。 Environment: Windows 10 64bit latest update, FF and windows in zh-tw variant. 1. What happened FF63->FF64 updated, and this font rendering/font changing behavior occurred. No idea it's intended or not intended. Facebook(and other zh-tw sites) will render fonts in ugly bold. 2. Expected results Fonts stays the same. Since font change's not mentioned in changelog, nor is the change in line with other browsers such as chrome. (FF63=chrome font; FF64!=chrome font) 3. Actual results Fonts become unbearably bold. 4. Observations The following images were screenshotted by mozregression, new vintage profile. https://www.dropbox.com/s/8xaw1yvum5eefh5/%E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.22.09.png?dl=0 https://www.dropbox.com/s/t33i6n2yh9jzbkn/%E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.22.19.png?dl=0 FF64 https://www.dropbox.com/s/qmck4acr1tebtd4/%E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.24.18.png?dl=0 FF65 FF63(expected result) https://www.dropbox.com/s/ttsbdhf6mrrz0p7/%E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.25.34.png?dl=0 5. Possible ways to circumvent 5.a. by changing fonts in about:preferences Not working, at all, every combination of options were changed, but Facebook fonts stayed the same. Likely a separated bug? 5.b. by changing fonts in about:config Not tested yet. Will cope if needed. 6. Problematic commit Via mozregression, the commit which changed the font is this one: https://bugzilla.mozilla.org/show_bug.cgi?id=1394709
Comment 7•5 years ago
|
||
Regression from 64 impacting the zh-tw locale.
Extra discussions: 1.Is the default zh-tw font change to JhengHei intended ->if no, we should fix that. ->if yes-> 2.Is the current font rendering behavior intended ->if no, we should fix that. ->if yes-> 3.Is it really necessary to force change upon user for sole aesthetics purpose? Arguments in 3: a. If it aint' broke, don't fix it. Force users to change will create outrage. Do that only when it's utterly necessary.(e.g., webextension) b. The font before change(FF63) is the same as Chrome, and zh-tw users are familiar with that. Unless you wanna create differences... c. Not my argument, but I saw(imprecise sampling method, yeah, I know..) 10+ ppl crying about this change, and some of them said that this is the last straw on the camel's back, they're done with Firefox. Shouldn't we stop chrome from becoming a huge monster with ridiculous market share?
Comment 9•5 years ago
|
||
> As a open source spirit doer, I hate seeing the market share of Firefox keep dropping.
> Shouldn't we stop chrome from becoming a huge monster with ridiculous market share?
Please keep only comment about technical issues. This isn't bringing value to this technical discussion.
Reporter | ||
Comment 10•5 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #9) > > As a open source spirit doer, I hate seeing the market share of Firefox keep dropping. > > Shouldn't we stop chrome from becoming a huge monster with ridiculous market share? > > Please keep only comment about technical issues. This isn't bringing value > to this technical discussion. Will cope. Sorry I didn't check the (CoC?) before posting dumb things.
Comment 11•5 years ago
|
||
(In reply to a29988122 from comment #6) > カトさん: > 怒りに任せてバグのリポートに誤解を招いて申し訳ありません。 no problem. We need technical description whether this is bug or we need fix this. > 改めて正式のフォーマットでもう一度試します。 > > Environment: > Windows 10 64bit latest update, FF and windows in zh-tw variant. > > 1. What happened > FF63->FF64 updated, and this font rendering/font changing behavior occurred. > No idea it's intended or not intended. > Facebook(and other zh-tw sites) will render fonts in ugly bold. > > 2. Expected results > Fonts stays the same. Since font change's not mentioned in changelog, nor is > the change in line with other browsers such as chrome. (FF63=chrome font; > FF64!=chrome font) > > 3. Actual results > Fonts become unbearably bold. > > 4. Observations > > The following images were screenshotted by mozregression, new vintage > profile. > https://www.dropbox.com/s/8xaw1yvum5eefh5/ > %E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.22.09.png?dl=0 > https://www.dropbox.com/s/t33i6n2yh9jzbkn/ > %E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.22.19.png?dl=0 > FF64 > > https://www.dropbox.com/s/qmck4acr1tebtd4/ > %E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.24.18.png?dl=0 > FF65 > > FF63(expected result) > https://www.dropbox.com/s/ttsbdhf6mrrz0p7/ > %E8%9E%A2%E5%B9%95%E6%88%AA%E5%9C%96%202019-01-07%2019.25.34.png?dl=0 Thank you. Facebook's CSS uses "Helvetica, Arial, sans-serif;" for font-family. So I think Firefox 64+ is expected result if font-family: sans-serif. And Facebook uses lang="zh-hant", so Firefox 64 won't recognize this lang attribute, but it will be fixed by bug 1503157. So changing font of zh-TW won't work on Firefox 64. But devtools recognizes "font-family: inherit;".... a29988122, what language version of your Windows 10? It may depend on pre-installed font.
Reporter | ||
Comment 12•5 years ago
|
||
zh-tw Windows 10 edu version, build 1809
Comment 13•5 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
Regression from 64 impacting the zh-tw locale.
Too late for 64.
Comment 14•5 years ago
|
||
Tracking for 65, but we've only got one more Beta build this week before next week's RC, so time's already pretty short to get a fix landed in time :\
Comment 15•5 years ago
|
||
Hi Sean, This was marked tracking-firefox65 (beta) yesterday; so relman is asking for an owner in case they have questions as Fx 65 approaches release. Can you talk with jkew and figure out the best plan for this one? Thanks.
Assignee | ||
Comment 16•5 years ago
|
||
ISTM this is primarily a question for m_kato, who I think knows more about CJK font settings, and for the MozTW folk. Bug 1394709 (initially landed for nightly/early-beta, extended to all channels in bug 1498438) was intended to change default fonts in some cases. So this seems generally like expected behavior.
However, given the pushback, maybe we should consider holding back (reverting) that change until bug 1475148 lands, which will make it easier for users to see/adjust the setting if they're unhappy with the updated default.
:m_kato, :petercpg, what do you think here?
Updated•5 years ago
|
Comment 17•5 years ago
|
||
(In reply to Makoto Kato [:m_kato] from comment #11)
Thank you. Facebook's CSS uses "Helvetica, Arial, sans-serif;" for
font-family. So I think Firefox 64+ is expected result if font-family:
sans-serif. And Facebook uses lang="zh-hant", so Firefox 64 won't recognize
this lang attribute, but it will be fixed by bug 1503157. So changing font
of zh-TW won't work on Firefox 64.
Testing on 64.0.2 with a new profile created on Windows 10 1809, both OS and browser in native zh-TW with JhengHei & PMingLiU installed. I was not able to reproduce the issue 5a as reported in Comment 6 (i.e., Facebook font does change after picking other ones from drop-down list in "Language and Appearance" in about:preferences.)
Screenshot when default font (font.name.sans-serif.zh-TW) was changed to DFKai-SB (aka. 標楷體)
https://www.dropbox.com/s/w3upij1zsnd0qbn/2019-01-17_011754.png?dl=0
https://www.dropbox.com/s/hfucxn2o69wkewi/2019-01-17_012500.png?dl=0
This is expected isn't it?
(In reply to Jonathan Kew (:jfkthame) from comment #16)
However, given the pushback, maybe we should consider holding back (reverting) that change until bug 1475148 lands, which will make it easier for users to see/adjust the setting if they're unhappy with the updated default.
:m_kato, :petercpg, what do you think here?
I'll leave that decision to Kato-san. It would be great if we could make it fixed on time but I'm fine if we are going to hold it until next train.
Showing Arial as default font is, and have been misleading due to historical problem of PMingLiU in zh-TW Windows, however, I think it's only a blocking issue if it was causing our users unable to tweak the preference?
Comment 18•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #16)
ISTM this is primarily a question for m_kato, who I think knows more about CJK font settings, and for the MozTW folk. Bug 1394709 (initially landed for nightly/early-beta, extended to all channels in bug 1498438) was intended to change default fonts in some cases. So this seems generally like expected behavior.
However, given the pushback, maybe we should consider holding back (reverting) that change until bug 1475148 lands, which will make it easier for users to see/adjust the setting if they're unhappy with the updated default.
:m_kato, :petercpg, what do you think here?
Facebook with zh-TW lang uses sans-serif. (Facebook may add a specific font such as Meiryo on ja-JP page). So if we detect zh-TW page, serif shouldn't be used if user doesn't customize font preference. TW users hope that sans-serif should use PMingLiU that is serif forever, I can have to revert to old. (But this causes performance issue, so we will change order of this list)
But as long as I test on Chrome 73 with the following html, sans-serif uses JhengHei. (Before landing bug 1498438, Firefox will use PMingLiU for sans-serif.)
<div id=d1 lang="zh-hant" style="font-family: sans-serif;">動態消息</div>
<div id=d2 lang="zh-hant" style="font-family: serif;">動態消息</div>
But reporter says Chrome uses PMingLiU from facebook's screenshot. So his environment is another setting that he doesn't say.
Reporter | ||
Comment 19•5 years ago
|
||
I'll leave my judgment alone from now on, preventing making things more complex; but I'll have to say: zh-tw user of Windows are really really really used to read MingLiu and PMingLiu - serif fonts - on Desktop websites.
Not only facebook.
Major social network sites, news sites and forums such as telnet bbs PTT and plurk are using MingLiu as their main display font(serif) - or at least that's the rendering result on most ppl's Windows browser, whether it's FF63 or Chrome.(Edge indeed uses JhengHei.)
Supporting evidence of said sites:
1.Yahoo news
2.Plurk
3.PanScience
4.PTT forum (People complained about JhengHei messing up their FF browser extension, and also complaining about not able to customize their font in about:preferences.)
Reply in order:
Q1. Default display font on Facebook on newly installed Chrome?
A: In VM, without login into Chrome/Google account, this is the result:
https://imgur.com/G6QXKxS
And it's exactly the same settings as in my host OS, the rendering / display result of Facebook is also the same - serif font(MingLiu I guess?).
I don't get it at all.
You are definitely more capable than me & understand what you're talking about, but I just can't reproduce a result where Chrome's default font's JhengHei, no matter which zh-tw sites is it.
Two results in host OS Chrome:
https://imgur.com/a/F7bnYnz
Not only VM with a fresh profile, I even tried another 2 PCs not owned by me, same results(serif fonts nearly everywhere).
Q2. #comment 17 About reproducing unable to customize font behavior.
I too CANNOT reproduce my previous results. The font customization behavior (at least on Facebook) is normal now. Tried to reproduce it in 64.01a 63.01a, and failed. It worked normally.
Like why the hell? 沒有放乖乖?
But I couldn't be daydreaming before. I did experiment myself thoroughly and check for discussions to see if I'm sane or not.
推 playerlin:
https://www.ptt.cc/bbs/Browsers/M.1544538427.A.591.html
Here's one of the discussion in zh-tw by Playerlin.
And there's also one complaint from my SO's laptop, which I did not touch at all(so no weird customization).
I had used Teamviewer to modify her FF's font settings, same results, unable to customize.
Trying to sum up(although I'm relatively lack of necessary knowledge):
-
Can't customize font bug -
Not able to reproduce. -
The default value of font.name-list.sans-serif.zh-TW, whether it's to remove Arial from it, or add JhengHei to it -
No idea. Honestly I don't get it because of my relatively lack of knowledge even after 6~10 hours of research.
Whether they will cause unwanted behavior, bug or not, it depends on you guys. -
The aesthetic choice of JhengHei/MingLiu as default font -
See the top of this post.
Also, check this research.
https://www.sciencedirect.com/science/article/pii/S0042698905003007#bib17
We're talking about Desktop environment, so size introduced legibility decrease in Experiment 1 should not matter on desktop monitor settings. It's not even a problem on normally printed papers.
Did I forget anything?
Assignee | ||
Comment 20•5 years ago
|
||
After discussion among Layout / Graphics management, the consensus is that we should revert the change of default font for the time being, given that it is affecting major sites and seems to be unwelcome for at least some users. This patch moves JhengHei to the end of the list for late-beta/release builds, so that PMingLiU will take precedence. Nightly/early-beta builds will continue to use the updated pref (which in principle seems more correct).
Updated•5 years ago
|
Updated•5 years ago
|
Comment 21•5 years ago
|
||
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/39296d5b2c92 Move JhengHei to the end of zh-TW sans-serif font prefs on late-beta/release so that previous default of PMingLiu will take precedence for now. r=m_kato
Comment 22•5 years ago
|
||
Please fill the uplift request for beta then.
Thanks
Assignee | ||
Comment 23•5 years ago
|
||
Comment on attachment 9037617 [details] [diff] [review] Move JhengHei to the end of zh-TW sans-serif font prefs on late-beta/release so that previous default of PMingLiu will take precedence for now [Beta/Release Uplift Approval Request] Feature/Bug causing the regression: bug 1394709 + bug 1498438 User impact if declined: Change to the default sans-serif font for zh-TW affecting major sites is surprising/unwelcome to some users Is this code covered by automated tests?: No Has the fix been verified in Nightly?: No Needs manual test from QE?: No If yes, steps to reproduce: List of other uplifts needed: None Risk to taking this patch: Low Why is the change risky/not risky? (and alternatives if risky): Simple re-ordering of font list in prefs so that the previous default again takes precedence; no effect on other locales or on content where fonts are explicitly named String changes made/needed: none
Comment 24•5 years ago
|
||
bugherder |
Comment 25•5 years ago
|
||
Comment on attachment 9037617 [details] [diff] [review] Move JhengHei to the end of zh-TW sans-serif font prefs on late-beta/release so that previous default of PMingLiu will take precedence for now [Triage Comment] Reverts the change to make the JhengHei font take precedence for zh-TW fonts in release builds due to jarring UX. Approved for 65.0rc1.
Comment 26•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Description
•