Wrong system font used for rendering
Categories
(Core :: Graphics: Text, defect)
Tracking
()
People
(Reporter: pierre-bugzilla, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
Firefox font settings
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0
Steps to reproduce:
- Configure DejaVu as the system default font
- Visit a page that uses "font-family: sans-serif;"
Actual results:
Page is rendered using Noto Sans.
Expected results:
Page should be rendered using DejaVu Sans.
|
Reporter | |
Comment 1•1 year ago
|
||
Both Firefox and the system clearly show that DejaVu is the configured font,
yet Noto is still picked for rendering:
$ fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Regular"
This is a regression when upgrading to Firefox 124.
|
||
Comment 2•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Text' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•1 year ago
|
||
Could you attach the details in about:support? Could you also let us know the website(s) you see the wrong font used on?
|
|
Reporter | |
Comment 4•1 year ago
|
||
|
|
Reporter | |
Comment 5•1 year ago
|
||
Attached the output from about:support.
One example site is this bugzilla here. font-family is computed as sans-serif, "FiraGO". But the "Fonts" tab in the inspector shows Noto Sans/Noto Sans Regular.
Of note is that Firefox' built in pages don't have this bug. E.g. about:support uses the system UI font ("Ubuntu" on this machine), but changing font-family to sans-serif give me the expected DejaVu there, not Noto.
Also of note is that I have a seemingly identical setup on a different machine. But the bug does not appear there. So there is something subtle involved here.
|
|
Reporter | |
Comment 6•1 year ago
|
||
The problem seems to be in my profile somehow. It goes away if I create a new profile.
The issue doesn't seem to be my addons, though, as the bug remains if I restart in "Troubleshoot Mode".
|
|
Reporter | |
Comment 7•1 year ago
|
||
The problem is also not browser.display.use_document_fonts. The bug is still present with that enabled.
I don't see any other interesting font settings. Suggestions?
|
||
Comment 8•1 year ago
|
||
I wonder if this is related to anti-fingerprinting font visibility restrictions. It looks like you're on Fedora, where I don't think DejaVu is one of the default-installed families, so it may be being blocked from web pages so that its presence can't be detected by sites and used as part of a tracking "fingerprint".
If you go into about:config and set privacy.fingerprintingProtection.overrides to the string -FontVisibilityLangPack (note the initial hyphen), does that affect the behavior? (You may need to quit and relaunch the browser for that to take effect, I'm not sure if it's a "live" setting.)
|
|
||
Updated•1 year ago
|
|
|
Reporter | |
Comment 9•1 year ago
|
||
Bingo! That did indeed resolve it!
(and it did require a restart of Firefox)
I'm very confused why this only affects one of my profiles, though. Some of my other privacy settings?
|
|
||
Comment 10•1 year ago
|
||
Since this works as intended, should we close this bug?
Though from a UX perspective it would be nice if we could show a message in the font selection saying that it won't get applied due to fingerprinting protection.
What would be the appropriate component to move this to? I can't seem to find a UX component in core.
|
|
||
Comment 11•1 year ago
|
||
This reminds me of bug 1863574, where we implemented a mechanism to allow CSS generics to be resolved without reference to visibility restrictions. I wonder if that isn't working as expected here. Let's keep this open for a little further investigation for now, at least until we have a more complete understanding of the exact case.
Pierre, would you mind attaching the about:support details from your affected profile, so we can see what other preferences etc might be present? Thanks.
|
|
Reporter | |
Comment 13•1 year ago
|
||
|
|
Reporter | |
Comment 14•1 year ago
|
||
about:support has now been attached. Note that this is with the workaround applied.
(In reply to Teodor Tanasoaia [:teoxoy] from comment #10)
Since this works as intended, should we close this bug?
Though from a UX perspective it would be nice if we could show a message in the font selection saying that it won't get applied due to fingerprinting protection.What would be the appropriate component to move this to? I can't seem to find a UX component in core.
This is a pretty major functionality break, so I would really hope you do not consider this "working as intended". Google's fonts are really bad on standard DPI monitors, as Google only seem to care about Android and hence don't bother with the hinting required if you don't have 200+ DPI.
|
|
||
Comment 15•1 year ago
|
||
Bug 1827475 tracks issues related to restricting font visibility, so I'll cross-reference this report there for the team's consideration.
|
||
Comment 16•1 year ago
|
||
Maybe a duplicate of bug 1880901? Seems to be the same issue, just different preferred fonts by the users.
The workaround mentioned here is seemingly more narrow, though. Perhaps that should be mentioned on the other bug?
|
||
Updated•1 year ago
|
Description
•