1382565 - The word spacing is too large when display the character " ' "

Status: NEW

(Firefox :: General, defect, P5)

Description

[Alastor Wu [:alwu]]

Attachment: word spacing is too large

See the attachment, I've mark the wrong place with red line square.
You can see the word spacing in those square is too large and it's not consistent with other words.

Comment 1

[[e-mail]]

Thanks for report! Can you share your running OS & version or if you have changed the default font, those infomation will help.

Comment 2

[Alastor Wu [:alwu]]

On OSX 10.11.4, using the default font.

Comment 3

[[e-mail]]

Attachment: normal on OSX 10.12.5

It looks normal on OSX 10.12.5, so this might be a OS specific issue

Comment 4

[Alastor Wu [:alwu]]

(In reply to Fred Lin [:gasolin] from comment #3)
> Created attachment 8888670 [details]
> normal on OSX 10.12.5
> 
> It looks normal on OSX 10.12.5, so this might be a OS specific issue

Not agree, because I got the same issue on Window7 with Nightly 56.0a1.

Comment 5

[[e-mail]]

Justin, could you help confirm if there's any other affect OS version?

Comment 6

[[e-mail]]

If it only happens in about:home,

Please try to patch aboutHome.css (or open devtools to add)

```
body {
  ...
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Ubuntu', 'Helvetica Neue', sans-serif;
}
```

http://searchfox.org/mozilla-central/source/browser/base/content/abouthome/aboutHome.css#15

And see if the issue is gone

Comment 7

[Alastor Wu [:alwu]]

(In reply to Fred Lin [:gasolin] from comment #6)
> If it only happens in about:home,
> 
> Please try to patch aboutHome.css (or open devtools to add)
> 
> ```
> body {
>   ...
>   font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Ubuntu',
> 'Helvetica Neue', sans-serif;
> }
> ```
> 
> http://searchfox.org/mozilla-central/source/browser/base/content/abouthome/
> aboutHome.css#15
> 
> And see if the issue is gone

Yes, the problem is solved after adding that line.

Comment 8

[[e-mail]]

the about:home's default font family affect the string presentation in onboarding tour for some users

Comment 9

[[e-mail]]

Attachment: Bug 1382565 - add default font-family for about:home;

Review commit: https://reviewboard.mozilla.org/r/159710/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/159710/

Comment 10

[[e-mail]]

the font-family style comes from activity stream http://searchfox.org/mozilla-central/source/browser/extensions/activity-stream/data/content/activity-stream.css#67

Comment 11

[:Gijs (he/him)]

Comment on attachment 8888678 [details]
Bug 1382565 - add default font-family for about:home;

https://reviewboard.mozilla.org/r/159710/#review165090

::: browser/base/content/abouthome/aboutHome.css:21
(Diff revision 1)
>    margin: 0;
>    display: -moz-box;
>    -moz-box-orient: vertical;
>    width: 100%;
>    height: 100%;
> +  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Ubuntu', 'Helvetica Neue', sans-serif;

r- for blinkMacSystemFont (which is, uh, from Blink, not something gecko recognizes or deals with, AIUI), but also because this list should be different per-platform, and finally because this shouldn't be on body but on the onboarding overlay, given that that's what needs it. Doing it elsewhere risks breaking about:home labels in other locales.

TBH, to begin with the correct approach here is to find out what font we're using for the onboarding stuff that looks so bad, why we're using that font, and why it's doing the wrong thing. I don't see any of that on this bug.

Certainly Windows uses different default fonts for different languages of Windows, and I would not be surprised if OS X did the same. Given that the list already mimics the en-US defaults of various OSes, we would be overriding those locale-specific defaults with the defaults of our own, which doesn't seem like the right thing to do.

Comment 12

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Here the default message-box font is used across the whole about:home page.
As a result, under Traditional Chinese environment, it chooses Microsoft JhengHei, a default font for Traditional Chinese since Windows 7.

Since single quote belongs to CJK ambiguous characters, it'd sometimes being resolved to full-width characters by font engine, especially for Chinese fonts. That would looks right when it is put together with Chinese characters; but unfortunately not in our case. 
See:
http://www.unicode.org/reports/tr11/tr11-31.html#Ambiguous

This is a long-persist issue on Chinese systems. The simplest solution is change it to a pure Latin font.
If there are any single quote used in original about:home, same issues appear. So I think putting it in about:home makes sense. If we want to do things more delicate we can even limit the rule to just for Chinese systems... But I'm not sure if it's necessary, given Activity Stream sets a default font-family directly too.

On the other hands, in Traditional Chinese single quote is seldom used. So after l10n is done, this issue would not likely to appear for Traditional Chinese version since the translations is not likely to contain single quote. This would only occur for English version users under Chinese system.

Comment 13

[:Gijs (he/him)]

(In reply to KM Lee [:rexboy] from comment #12)
> This is a long-persist issue on Chinese systems. The simplest solution is
> change it to a pure Latin font.
> If there are any single quote used in original about:home, same issues
> appear. So I think putting it in about:home makes sense. If we want to do
> things more delicate we can even limit the rule to just for Chinese
> systems...


> ... this issue would not likely to appear for Traditional
> Chinese version since the translations is not likely to contain single
> quote. This would only occur for English version users under Chinese system.


My concern isn't about Chinese Firefox on a Chinese Windows/OSX, but about Chinese (or Vietnamese, or Tagalog, or...) Firefox on their respective OSes. The default right now would be to use an OS-language-suitable font. The change proposed on this bug would use an en-US-suitable font at all times, even on Firefoxen that aren't using that language. That doesn't seem like it's the right solution.

Furthermore, for users who have customized their OS font, this change would now start overriding users' preferences.

Is there an alternative solution we could use? For instance, can we force Gecko to recognize that because the ambiguous apostrophe character is used in Latin text, it should also be rendered with a Latin font?

> But I'm not sure if it's necessary, given Activity Stream sets a
> default font-family directly too.

Other people doing the wrong thing doesn't make doing the wrong thing OK...

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8888678 [details]
Bug 1382565 - add default font-family for about:home;

https://reviewboard.mozilla.org/r/159710/#review166050

::: browser/base/content/abouthome/aboutHome.css:21
(Diff revision 1)
>    margin: 0;
>    display: -moz-box;
>    -moz-box-orient: vertical;
>    width: 100%;
>    height: 100%;
> +  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Ubuntu', 'Helvetica Neue', sans-serif;

I agree this doesn't have to be this complex. Simply `font-family: san-serif` should be enough, since on zh-TW we default to English font first.

https://dxr.mozilla.org/mozilla-central/rev/7d2e89fb92331d7e4296391213c1e63db628e046/modules/libpref/init/all.js#3622

> Is there an alternative solution we could use? For instance, can we force Gecko to recognize that because the ambiguous apostrophe character is used in Latin text, it should also be rendered with a Latin font?

There isn't a good way to fix UAX#11 ambiguous width other than selectively change the font. If we couldn't agree on changing the font from `message-box` to `sans-serif` where Gecko has better control, I would recommend we WONTFIX this bug.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Rex, do you know why we check-in |message-box| at first place? Could you point me the spec? What harm it would do if we move to |sans-serif|? Please follow this up with UX and maybe propose a proper patch in place of Fred if they agrees.

Comment 16

[KM Lee [:rexboy] (inactivate after Sep. 22)]

Attachment: sans-serif on mac

Pretty awful to me. :-/ I guess that's why the font-face is not a single sans-serif.

Comment 17

[KM Lee [:rexboy] (inactivate after Sep. 22)]

These check-in came from earlier days, where message-box is replaced for all in-content UIs to replace hard-code windows font names.
Some discussion I found can be seen in bug 630777, bug 631598 comment 2, and bug 711157 comment 12.
sans-serif is replaced intentionally to make it looks more consistent with the system UI. But unfortunately it didn't solve the CJK issue well on windows.

On Onboarding, we just use "system font" on spec, which seems to be consisent to the decision on those bug above.

After these study I start to tend to do WONTFIX too because seems we need to invent a good font-family sequence that works across languages and works better than |message-box|.

Comment 18

[KM Lee [:rexboy] (inactivate after Sep. 22)]

sorry for the invalid ni?. I'm still typing.

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to :Gijs from comment #13)
> Is there an alternative solution we could use? For instance, can we force Gecko to recognize that because the ambiguous 
> apostrophe character is used in Latin text, it should also be rendered with a Latin font?

I've once started a thread about this on www-style. I am thinking about raising the same question again as css-text spec issues. That would take some time to cook, let along implement, so this bug certainly cannot depend on that.

Comment 20

[Francis Lee [:frlee]]

per discussion with UX approval, move this to P3.

Comment 21

[:Gijs (he/him)]

If we think the situation of running latin builds on non-latin Windows/macOS is common enough to warrant fixing, one thing we could consider doing is setting the lang attribute (based on l10n settings) on the body from JS, and changing the font family for the body when it has that attribute. This would still be a compromise in that users' changes to OS message-box font settings would still not be respected, but it sounds like that would be the best we could do. Equally, I am not sure if that's worth doing or if we should WONTFIX, per the earlier discussion it seems like this is a thorny issue.

Either way, IMO we should use per-OS styling rather than lumping -apple-system with Segoe UI and Ubuntu.

Comment 22

[Tim Guan-tin Chien [:timdream] (please needinfo)]

The lang attribute won't fix anything as long as we stick to `message-box`, which points to a Chinese font on Windows zh-TW.

I hate to throw out crazy ideas, but just like color Emoji detection, you could measure the width of characters with Canvas2DContext ... it would be an overkill though.

Comment 23

[:Gijs (he/him)]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #22)
> The lang attribute won't fix anything as long as we stick to `message-box`,
> which points to a Chinese font on Windows zh-TW.

Sure, I meant, the patch that's currently on the bug hardcodes en-US fonts even in other locales where this would be "wrong". We could use the lang attribute to only specify fonts for en-US (and/or other latin) builds, which would somewhat reduce the negative impact, though as noted in my earlier comment that would still break user OS preferences for the message-box font on en-US builds.