1413145 - Can't set UI font to sans-serif

Status: UNCONFIRMED

(Core :: XPCOM, defect)

Description

[lilydjwg]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171029220112

Steps to reproduce:

I set the following prefs to make the browser UI to use a sans-serif font:

font.default.x-unicode;sans-serif
font.default.x-western;sans-serif


Actual results:

The browser UI (tab text, urlbar, etc) still uses a serif font for ASCII characters.


Expected results:

The browser UI should use a sans-serif font for ASCII characters like before 2017-10-26.

mozregression gives me this:

Found commit message:
Bug 1411893 - Introduce nsStaticAtom. r=emilio,froydnj.

It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)

MozReview-Commit-ID: 4Q6QHX5h44V

Comment 1

[Nicholas Nethercote [inactive]]

Thank you for the report. I'm surprised that bug 1411893 is the cause, it should have not had any effect on any visible functionality.

I've tried reproducing on my Ubuntu box. I tested a build from just before that commit, as well as one quite a bit before. Even with those older versions I can't get those prefs to have any observable effect on the browser UI. Even though the default is "serif", I think I have a sans-serif font by default anyway.

Comment 2

[lilydjwg]

I retried again, it still stopped at there. I'm attaching a screenshot from mozgression.

Does your nightly have sans-serif font for UI by default? I see serif font by default since I use nightly.

I'm on Arch Linux x86_64.

Comment 3

[lilydjwg]

Attachment: mozregression.png

Comment 4

[lilydjwg]

Minimal reproducible fontconfig:

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <match target="pattern">
    <test qual="any" name="family">
      <string>serif</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>DejaVu Serif</string>
    </edit>
  </match>
  <match target="pattern">
    <test qual="any" name="family">
      <string>sans-serif</string>
    </test>
    <edit name="family" mode="prepend" binding="strong">
      <string>Emoji One Color</string>
      <string>DejaVu Sans</string>
    </edit>
  </match>
</fontconfig>

It basically sets a serif font for "serif", and two sans fonts for "sans-serif". Firefox uses DejaVu Serif for UI. If I remove "Emoji One Color" the UI shows in DejaVu Sans by default. It even doesn't need those two prefs. In both cases Firefox doesn't use Emoji One Color (it doesn't have ASCII characters).

I don't know what's going on. What is the expected behaviour? Is serif or sans-serif expected by default?

Comment 5

[Nicholas Nethercote [inactive]]

I looked at this some more, specifically at the font.default.x-western pref. That pref defaults to "serif". 

- I visited http://njn.valgrind.org/, which is a page with no styling. The page text used a serif font.

- I changed the pref to "sans-serif", and the page text changed to a sans serif font. (The browser chrome text did not change, however.)

- I changed the pref to "monospace", and the page text changed to a monospace font. (Again, the browser text did not change.)

All this is with a current dev build, i.e. one that has bug 1411893's patches.

I don't know much about this pref, but this behaviour seems reasonable.

lilydjwg: can you try these steps? Can you can replicate the behaviour I described?

jkew: do you know about the font.default.x-{western,unicode} prefs, and whether the behaviours described in this bug seem reasonable or not? In particular, do those prefs affect browser chrome, or just web content?

Comment 6

[Jonathan Kew [:jfkthame]]

I thought the font.default.* prefs were only for content, and browser chrome would typically use the fonts it gets via Gtk APIs in widget/gtk/nsLookAndFeel.cpp.

Possibly, though, the code in GetSystemFontInfo (in nsLookAndFeel.cpp), which uses pango_font_description_get_family to extract the font family name, ends up returning only the first name that sans-serif resolved to (which would be Emoji One Color, in the reporter's configuration), so that's what we try to use for the browser chrome. And when that font doesn't include the relevant characters (e.g. Latin letters), we fall back as a last resort to the browser's default style (which would come from the font.default.* prefs, typically serif).

A bit of debugging to determine what we're getting for mDefaultFont etc in nsLookAndFeel, when the fontconfig setup inserts Emoji One Color in front of the "expected" sans-serif face, should be able to confirm whether this is what's happening. Basically, I think the issue is that our code to access UI font settings from Gtk doesn't support returning a list of fonts rather than a single family.

Comment 7

[Jonathan Kew [:jfkthame]]

FWIW, I don't see why bug 1411893 would have affected the behavior here. If we can reproduce that (by setting up a comparable fontconfig configuration, etc), it seems worth debugging to understand why something changed.

Comment 8

[lilydjwg]

Nicholas Nethercote: I can only replicate the behaviour when LANG=en_US.UTF-8, not when LANG=zh_CN.UTF-8.

It seems that those prefs are only meant for content. So when the first time I noticed the issue and changed the prefs, it worked unexpectedly, and this time it doesn't work because it's not expected?

I tried to replace Emoji One Color with Noto Color Emoji, and got the same result.

> I think the issue is that our code to access UI font settings from Gtk doesn't support returning a list of fonts rather than a single family.

It sounds this is the cause for my issue.