1165179 - Firefox chrome (UI) uses the serif font on Linux Mint

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[Cameron McCormack (:heycam)]

Attachment: screen shot

See the attached screen shot.  We are using a fallback serif font for chrome UI, when it should be using Noto Sans.

Comment 1

[John Daggett (:jtd)]

After working with Cameron a bit, the problem here is that the Noto Sans family that ships with Mint includes the faces of Noto Sans Khmer and Noto Sans Khmer UI. After adding the fonts on Cameron's system to my Ubuntu install, fc-list lists the following families for Noto Sans:

$ fc-list ":family=Noto Sans" 
/home/jd/.fonts/noto/NotoSans-Regular.ttf: Noto Sans:style=Regular
/home/jd/.fonts/noto/NotoSans-Italic.ttf: Noto Sans:style=Italic
/home/jd/.fonts/noto/NotoSansKhmerUI-Regular.ttf: Noto Sans,Noto Sans Khmer UI:style=Regular
/home/jd/.fonts/noto/NotoSansKhmer-Bold.ttf: Noto Sans,Noto Sans Khmer:style=Bold
/home/jd/.fonts/noto/NotoSansKhmer-Regular.ttf: Noto Sans,Noto Sans Khmer:style=Regular
/home/jd/.fonts/noto/NotoSansKhmerUI-Bold.ttf: Noto Sans,Noto Sans Khmer UI:style=Bold
/home/jd/.fonts/noto/NotoSans-Bold.ttf: Noto Sans:style=Bold
/home/jd/.fonts/noto/NotoSans-BoldItalic.ttf: Noto Sans:style=Bold Italic

The Noto Sans family name is coming from the family name in the name table, not from configuration swizzling as in the Debian Droid Sans "superfamily" case. But the outcome is the same, it appears the style matching chooses Khmer regular face since the cmap lacks glyphs for Latin it falls back.

I think the solution here may or may not end up being part of the solution to the superfamily matching problem, bug 1160506.

Comment 2

[John Daggett (:jtd)]

Argh, looks like Mint is shipping with a buggy version of Noto Sans Khmer:

https://code.google.com/p/noto/issues/detail?id=1

Comment 3

[Cameron McCormack (:heycam)]

Looks like this might be the case in Ubuntu too:

  http://packages.ubuntu.com/vivid/fonts-noto

vivid being the latest 15.04 release.

Comment 4

[Daniel Holbert [:dholbert]]

I'm running Vivid on two different machines, and I haven't seen this bug on either system.

Comment 5

[Tom S [:evilpie]]

I get the same bug and I am also on Linux Mint, but don't seem to have Noto Sans at all.

Comment 6

[Philipp Wagner [:imphil]]

Same here on OpenSUSE 13.2. Since the nightly including bug 1056479 I get serif fonts in the UI instead of the sans-serif ones before. (I'm guessing the issue, I didn't bisect this issue down to bug 1056479. If it helps I can certainly verify that.)

Is there anything I can provide from the system?

Comment 7

[Daniel Holbert [:dholbert]]

[Tracking Requested - why for this release]: (linux font-choice regression which makes the UI look weird & which we shouldn't ship.)

Comment 8

[John Daggett (:jtd)]

(In reply to Philipp Wagner [:imphil] from comment #6)
> Same here on OpenSUSE 13.2. Since the nightly including bug 1056479 I get
> serif fonts in the UI instead of the sans-serif ones before. (I'm guessing
> the issue, I didn't bisect this issue down to bug 1056479. If it helps I can
> certainly verify that.)
> 
> Is there anything I can provide from the system?

Yes, it would be helpful to know the UI fonts in use.

If you could run Firefox with textrun logging enabled that would give me a clue as to what is going on.

export NSPR_LOG_MODULES=textrunui:5,textrun:5
export NSPR_LOG_FILE=textrun.out
/path/to/firefox -P /path/to/profile

You can just start the browser and quit once the browser window displays.

If you could attach the textrun.out file that would be really helpful! With e10s there may be multiple file lurking about.

Comment 9

[Philipp Wagner [:imphil]]

John, thanks, I'll do that -- unfortunately I don't have access to the PC showing this problem until next week. I just tried it on my laptop, also running openSUSE 13.2, and there I don't see the problem. I'm guessing some LaTeX-installed fonts or something similar on the other machine are causing this, but I'll get back to you next week with the logs.

Comment 10

[Tom S [:evilpie]]

Attachment: textrun.out

I hope this is enough to help you.

Comment 11

[u412933]

I see the same in a Fedora 20 system, with Droid Sans as default system font (though I think that I don't have installed all the Droid family fonts). I can give further details and a textrun.out log tomorrow.

Comment 12

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Since this is a regression (and hoping has a simple fix), adding a tracking flag for firefox41.

Comment 13

[Philipp Wagner [:imphil]]

Attachment: [openSUSE 13.2] textrun.out

Comment 14

[Philipp Wagner [:imphil]]

Attachment: [openSUSE 13.2] textrun.out.child-1

Comment 15

[Philipp Wagner [:imphil]]

(In reply to John Daggett (:jtd) from comment #8)
> (In reply to Philipp Wagner [:imphil] from comment #6)
> > Same here on OpenSUSE 13.2. Since the nightly including bug 1056479 I get
> > serif fonts in the UI instead of the sans-serif ones before. (I'm guessing
> > the issue, I didn't bisect this issue down to bug 1056479. If it helps I can
> > certainly verify that.)
> > 
> > Is there anything I can provide from the system?
> [...]
> If you could attach the textrun.out file that would be really helpful! With
> e10s there may be multiple file lurking about.

I've attached both files from my system using a fresh profile. The oxygen stuff probably comes from the oxygen-gtk theme, which is used by default in openSUSE to make GTK2 look a bit more like Qt/KDE.

Comment 16

[John Daggett (:jtd)]

(In reply to Philipp Wagner [:imphil] from comment #15)

> I've attached both files from my system using a fresh profile. The oxygen
> stuff probably comes from the oxygen-gtk theme, which is used by default in
> openSUSE to make GTK2 look a bit more like Qt/KDE.

Thanks! Could you also attach the results of running this command:

  fc-list : | grep Oxygen

I'd like to see what the faces of Oxygen-Sans are

Thanks!

Comment 17

[John Daggett (:jtd)]

Tryserver build of a possible fix:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-1f3ed807bda6/

With this patch, all faces with the same style are included in the set of fonts included for a given family/style combination, rather than just one.

Comment 18

[Philipp Wagner [:imphil]]

(In reply to John Daggett (:jtd) from comment #16)
> (In reply to Philipp Wagner [:imphil] from comment #15)
> 
> > I've attached both files from my system using a fresh profile. The oxygen
> > stuff probably comes from the oxygen-gtk theme, which is used by default in
> > openSUSE to make GTK2 look a bit more like Qt/KDE.
> 
> Thanks! Could you also attach the results of running this command:
> 
>   fc-list : | grep Oxygen

This does not output anything (including grep -i and manually looking through the file).

I also tried the tryserver build [e-mail]-1f3ed807bda6/ that you linked above, but the UI still has serif fonts.

Comment 19

[John Daggett (:jtd)]

(In reply to Philipp Wagner [:imphil] from comment #18)
> > Thanks! Could you also attach the results of running this command:
> > 
> >   fc-list : | grep Oxygen
> 
> This does not output anything (including grep -i and manually looking
> through the file).
> 
> I also tried the tryserver build [e-mail]-1f3ed807bda6/ that you
> linked above, but the UI still has serif fonts.

Hmmm, mysterious. Ok, could you just attach the full results of the command below?

  fc-list : >fclist.out

It would also be handy to have fontlist logging, if it's not too much bother:

export NSPR_LOG_MODULES=fontlist:5
export NSPR_LOG_FILE=fontlist.out
/path/to/firefox -P /path/to/profile

Comment 20

[John Daggett (:jtd)]

Cameron reports that for the Mint case, the tryserver build in comment 17 now shows the standard UI sans-serif font (i.e. Noto Sans).

Tom, do you see the right font with the tryserver build?

Comment 21

[Philipp Wagner [:imphil]]

Attachment: [openSUSE 13.2] fontlist.out

Comment 22

[Philipp Wagner [:imphil]]

Attachment: [openSUSE 13.2] fontlist.out.child-1

Comment 23

[Philipp Wagner [:imphil]]

Attachment: [openSUSE 13.2] fclist.out

Comment 24

[Philipp Wagner [:imphil]]

(In reply to John Daggett (:jtd) from comment #19)
> Hmmm, mysterious. Ok, could you just attach the full results of the command
> below?
> 
>   fc-list : >fclist.out
> 
> It would also be handy to have fontlist logging, if it's not too much bother:
> 
> export NSPR_LOG_MODULES=fontlist:5
> export NSPR_LOG_FILE=fontlist.out
> /path/to/firefox -P /path/to/profile

It's all attached.

Comment 25

[Tom S [:evilpie]]

John: No same wrong font as before.

Comment 26

[John Daggett (:jtd)]

(In reply to Philipp Wagner [:imphil] from comment #24)

> It's all attached.

Thanks for slogging through this. It looks like your problem is caused by GetDefaultFont always returning the default serif, when it should just be returning whatever font fontconfig suggests when no name in the family list exists. In your case, it looks like the theme code missed installing a font (i.e. Oxygen-Sans) which was causing the default font to be used. That will normally just be something like DejaVu Sans, whatever the result of 'fc-match :' is.

I've filed a separate bug for that, bug 1170421.

Comment 27

[Tom S [:evilpie]]

Bug went away for me.

Comment 28

[Philipp Wagner [:imphil]]

Cameron, is this solved for you as well in a recent Nightly?

Comment 29

[Cameron McCormack (:heycam)]

I tested last week, after bug 1170421 landed I think, and it wasn't fixed for me.  (I don't have access to that machine until next week to do any more testing, though.)

Comment 30

[Philipp Wagner [:imphil]]

I did a bit of testing to see where we actually still have a problem:

- openSUSE 13.2 with KDE looks good: both on a fresh install and on my (possibly weird) setup, I get normal fonts in recent nightlies (since bug 1170421)

- Ubuntu 15.04 (Gnome) looks good (live CD == default install)

- Kubuntu 14.04 LTS (KDE) looks good as well  (live CD == default install)


- Linux Mint: "Linux Mint 17.1 "Rebecca" - Cinnamon (64-bit)" shows serif fonts (tested using the Live CD, thus easily reproducible and present in the standard installation)

This brings this bug back to where it started :)

Comment 31

[Clément Lefèvre]

I noticed a quite similar behavior but with stranger elements on ArchLinux, so I'll mention it, in case it would be related.

I also got strange fonts on chrome, on both the profile manager and the window chrome.
It became stranger when I noticed that with the same Nightly session, with several windows opened, only the first window does have this bug. Every other window uses normal and usual font.

I'll add screenshots after this comment to show this. It was tested on both usual profile and empty one.

Comment 32

[Clément Lefèvre]

Attachment: Profile manager with wrong font

Comment 33

[Clément Lefèvre]

Attachment: Profile manager with correct font

Comment 34

[Clément Lefèvre]

Attachment: Nightly windows. See difference between both.

Nightly windows. Both windows are from the same binary, same session, in the same time. Only one does have problem, the first one as stated in earlier comment.

The bug is now a couple of days old, maybe related to attemps to fix this one…or totally unrelated?

Comment 35

[u412933]

Attachment: [Fedora 20] Mix of sizes and fonts, after landing of bug 1170421

(In reply to Philipp Wagner [:imphil] from comment #30)
> This brings this bug back to where it started :)
You missed my mention :)

(In reply to Marco from comment #11)
> I see the same in a Fedora 20 system, with Droid Sans as default system font...

Now I can update my case. Today I tried again with a clean profile in Nightly to see the effects of the land of bug 1170421; I got a mix of things, see attachment:

* For comparation, I put at the bottom a SeaMonkey window showing the expected font.
* The main Nightly window shows now the correct font, but the size is wrong: it's bigger that the expected.
* The dialog triggered in the first run still shows the wrong font.

Comment 36

[John Daggett (:jtd)]

Attachment: patch, include all optimal style matched faces in fontlist

This adjusts the code within gfxFontGroup::FindPlatformFont to use the same logic for both downloadable fonts and system fonts. If there are several faces that are the same "closeness" to the specified font style, include all of these in the fontlist. This will effectively work around the Noto Sans Khmer problem but it's probably a good idea in general for font families under Linux, where font family organization can be a bit of a hodgepodge.

I suspect the other problems listed here are the result of the "super family" handling problem, where we need to effectively implement intra-family font fallback (argh!). That will be fixed via bug 1160506.

I ran tryserver builds to confirm that this doesn't affect tp perf.

Comment 37

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/57d2ee3597f9

Comment 38

[John Daggett (:jtd)]

Please leave open, as I want to make sure all the various problems listed in comments get resolved after the "super family" bug is resolved.

Comment 39

[Clément Lefèvre]

For those noticed on Archlinux by me, from comment 31 to 34, problem is now gone.

Comment 40

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/57d2ee3597f9

Comment 41

[John Daggett (:jtd)]

Comment on attachment 8628572 [details] [diff] [review]
patch, include all optimal style matched faces in fontlist

Approval Request Comment
[Feature/regressing bug #]: 1056479
[User impact if declined]: UI fonts will be incorrect for some Linux distros
[Describe test coverage new/current, TreeHerder]: stable, users of affected distros report this is fixed
[Risks and why]: might affect font lookup performance but not impact in perf seen
[String/UUID change made/needed]: none

Comment 42

[John Daggett (:jtd)]

(In reply to Marco from comment #11)
> I see the same in a Fedora 20 system, with Droid Sans as default system font
> (though I think that I don't have installed all the Droid family fonts). I
> can give further details and a textrun.out log tomorrow.

This is bug 1160506 I think. I'm going to resolved this as fixed. We can reopen and/or open new bugs if UI font problems still exist for certain distros.

Comment 43

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Removing keyword leave-open as the bug has been resolved as fixed. status-firefox42: should be fixed.

Comment 44

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8628572 [details] [diff] [review]
patch, include all optimal style matched faces in fontlist

comments indicate that the fix has been working as expected. Let's get this patch into Aurora.

Comment 45

[u412933]

(In reply to John Daggett (:jtd) from comment #42)
> (In reply to Marco from comment #11)
> > I see the same in a Fedora 20 system, with Droid Sans as default system font
> > (though I think that I don't have installed all the Droid family fonts). I
> > can give further details and a textrun.out log tomorrow.
> 
> This is bug 1160506 I think. I'm going to resolved this as fixed. We can
> reopen and/or open new bugs if UI font problems still exist for certain
> distros.

I tested today, using Nightly, and all looks fine now :) So Fedora case is OK.

Comment 46

[John Daggett (:jtd)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f0d415f22661

Comment 47

[u279076]

Verified fixed based on comment 45. Thank you for your help, Marco.