1850830 - Numbers being rendered in emojis instead of default font on some pages

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[Ryder Cutler]

Attachment: Bug shown on MSI support page

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

Simply visit a website which has numbers rendered on it. Worth noting this does not happen to every website, but I'm unsure what the common factor websites this happens on is.

Pages I have noticed this happening: https://www.msi.com/Motherboard/B450M-BAZOOKA-MAX-WIFI/support
https://reddit.com (specifically when numbers are in code blocks, see https://www.reddit.com/r/linuxquestions/comments/y9ngzf/why_wont_my_systemd_service_start_immediately/)

Actual results:

Numbers are rendered in the emoji font instead of the normal default font.

Expected results:

Numbers should instead be rendered in the default font.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (maybe)

Thanks for the bug report. Here's a possible testcase, using the font-family CSS values from what I think is the affected portions of the MSI and reddit pages that you linked.

Could you let us know whether you can reproduce the issue with this testcase?

Also, assuming you can reproduce with this testcase -- could you check Firefox's devtools to see what fonts Firefox is actually using to render the various parts of this text in this testcase? To do that:
(1) Right-click the page and choose "Inspect"
(2) At the top right of the devtools sidebar that appears, you should see a little downarrow menu-button (just below the "x"). Click that downarrow button.
(3) In the menu that appears, click "Fonts"
(4) That brings up a fonts pane, which will show you whatever fonts are used for the elemment that you pick in the leftmost pane.

And then let us know what the "Fonts Used" shows (it might show several), when you highlight the <div class="msi"> vs. when you highlight the <div class="reddit">.

Comment 3

[Daniel Holbert [:dholbert]]

Also:

• It looks like you're on Linux -- what distro/version are you using?
• Do you know what sort of Firefox package are you using -- e.g. it from a snap (the default on Ubuntu 22.04 and newer), or Flatpak, or a tarball downloaded from Mozilla, or another sort of package?

(If you're using a snap, for example: we've hit issues in the past where the snappified Firefox had a different font/text configuration from a tarball Firefox installation, due to an issue with the snap environment.)

Comment 4

[Daniel Holbert [:dholbert]]

Personally, I can't yet reproduce this issue locally in Firefox Nightly 119 (from mozilla's official tarball) or release 117 (as a snap) on Ubuntu 22.04, for what it's worth. I tried the links in comment 0 as well as my attached testcase.

Comment 5

[Ryder Cutler]

Thank you for the reply! I can confirm that the issue is reproduced with the testcase.

When I highlight <div class="msi"> the fonts being used are Clear Sans and Noto Color Emoji.
When I highlight <div class="reddit"> the fonts being used are Hack (Hack Regular) and Noto Color Emoji.

For the Linux distro I am using Solus 4.4 (currently the most recent version), and I downloaded it straight from their repos. I had already brought this issue up with them on their support channels and they suggested it was an upstream issue with Firefox.

If it means anything, I have since updated to Firefox 117 and the issue is still happening.

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Ryder Cutler from comment #5)

When I highlight <div class="msi"> the fonts being used are Clear Sans and Noto Color Emoji.
When I highlight <div class="reddit"> the fonts being used are Hack (Hack Regular) and Noto Color Emoji.

I notice that in both these cases, the (non-emoji) font you're getting is not among those named in the font-family property, which suggests you're probably getting whatever the "generic" font family in each case (sans-serif or monospace) resolves to. I guess the pages where this doesn't happen may be pages that are providing a specific webfont rather than relying on installed fonts via fontconfig.

The issue with numbers implies, I think, that the system's fontconfig setup prepends Noto Color Emoji to the list it returns when resolving these generic font names (or possibly it's aliasing one of the specific families listed in the CSS to a "similar" font, e.g. Helvetica or Arial -> Clear Sans), because it wants to ensure that emoji are available no matter what font is used. But by prepending the color-emoji font, that takes precedence for characters that it supports, which includes the ASCII digits (and a few punctuation characters: you may see the same issue with #, for instance).

So I suspect the root cause lies somewhere in the system's fontconfig configuration, but it'll take a bit of trawling through the config files to identify exactly what's happening. If you're comfortable doing that, you could look for references to Noto Color Emoji in fontconfig's *.conf files -- not sure where Solus puts them, maybe under /usr/share/fontconfig or similar -- to see how it's being inserted.

Comment 7

[Ryder Cutler]

(In reply to Jonathan Kew [:jfkthame] from comment #6)

Thank you for your suggestions! I believe I have found the culprit in the config file for Noto Colour Emoji. According to a comment it's used as a fallback for the entire Noto Family, and both of those test cases utilizes it, which I believe is what's causing the issue here.

Thank you all for your help!

Comment 8

[Jonathan Kew [:jfkthame]]

Aha - glad you were able to track it down! Thanks for letting us know.