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

VERIFIED FIXED in Firefox 41

Status

()

VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: heycam, Assigned: jtd)

Tracking

({regression})

Trunk
mozilla42
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox41+ fixed, firefox42 fixed)

Details

(Whiteboard: gfx-noted)

Attachments

(12 attachments)

(Reporter)

Description

4 years ago
Created attachment 8606102 [details]
screen shot

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

Comment 1

4 years ago
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.
(Assignee)

Comment 2

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

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

Comment 3

4 years ago
Looks like this might be the case in Ubuntu too:

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

vivid being the latest 15.04 release.
I'm running Vivid on two different machines, and I haven't seen this bug on either system.
I get the same bug and I am also on Linux Mint, but don't seem to have Noto Sans at all.
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?
[Tracking Requested - why for this release]: (linux font-choice regression which makes the UI look weird & which we shouldn't ship.)
tracking-firefox41: --- → ?
Keywords: regression
Summary: chrome fonts wrong on Linux Mint → Firefox chrome (UI) uses the wrong font, on Linux Mint & OpenSUSE
Depends on: 1160506
(Assignee)

Comment 8

4 years ago
(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.
(Assignee)

Updated

4 years ago
Assignee: nobody → jdaggett
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.
Created attachment 8607080 [details]
textrun.out

I hope this is enough to help you.

Comment 11

4 years ago
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.
Since this is a regression (and hoping has a simple fix), adding a tracking flag for firefox41.
tracking-firefox41: ? → +
Created attachment 8610161 [details]
[openSUSE 13.2] textrun.out
Created attachment 8610162 [details]
[openSUSE 13.2] textrun.out.child-1
(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.
(Assignee)

Comment 16

4 years ago
(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!
Flags: needinfo?(imphil)
(Assignee)

Comment 17

4 years ago
Tryserver build of a possible fix:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jdaggett@mozilla.com-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.
(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 jdaggett@mozilla.com-1f3ed807bda6/ that you linked above, but the UI still has serif fonts.
Flags: needinfo?(imphil)
Whiteboard: gfx-noted
(Assignee)

Comment 19

4 years ago
(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 jdaggett@mozilla.com-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
Flags: needinfo?(imphil)
(Assignee)

Comment 20

4 years ago
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?
Flags: needinfo?(evilpies)
Created attachment 8612107 [details]
[openSUSE 13.2] fontlist.out
Flags: needinfo?(imphil)
Created attachment 8612108 [details]
[openSUSE 13.2] fontlist.out.child-1
Created attachment 8612109 [details]
[openSUSE 13.2] fclist.out
(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.
John: No same wrong font as before.
Flags: needinfo?(evilpies)
(Assignee)

Updated

4 years ago
Depends on: 1170421
(Assignee)

Comment 26

4 years ago
(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.
Bug went away for me.
Cameron, is this solved for you as well in a recent Nightly?
Flags: needinfo?(cam)
(Reporter)

Comment 29

4 years ago
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.)
Flags: needinfo?(cam)
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 :)
Summary: Firefox chrome (UI) uses the wrong font, on Linux Mint & OpenSUSE → Firefox chrome (UI) uses the serif font on Linux Mint
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.
Created attachment 8623731 [details]
Profile manager with wrong font
Created attachment 8623733 [details]
Profile manager with correct font
Created attachment 8623735 [details]
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

4 years ago
Created attachment 8624915 [details]
[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.
(Assignee)

Comment 36

4 years ago
Created attachment 8628572 [details] [diff] [review]
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.
Attachment #8628572 - Flags: review?(cam)
(Reporter)

Updated

4 years ago
Attachment #8628572 - Flags: review?(cam) → review+
(Assignee)

Comment 38

4 years ago
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.
Keywords: leave-open
For those noticed on Archlinux by me, from comment 31 to 34, problem is now gone.
(Assignee)

Comment 41

4 years ago
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
Attachment #8628572 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 42

4 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Removing keyword leave-open as the bug has been resolved as fixed. status-firefox42: should be fixed.
status-firefox42: --- → fixed
Target Milestone: --- → mozilla42
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.
Attachment #8628572 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 45

4 years ago
(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.
(Assignee)

Updated

4 years ago
Keywords: leave-open
(Assignee)

Comment 46

4 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/f0d415f22661
status-firefox41: affected → fixed
Verified fixed based on comment 45. Thank you for your help, Marco.
Status: RESOLVED → VERIFIED
(Assignee)

Updated

3 years ago
Depends on: 1185812
You need to log in before you can comment on or make changes to this bug.