2012950 - Firefox 147.0.2 UI displays garbled characters instead of proper text in settings and menus

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P1)

Description

[Jack Jones]

Attachment: Firefox 147.0.2 UI Font Messed Up.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0

Steps to reproduce:

User Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0

1. Update Firefox from version 147.0.1 to version 147.0.2 on Windows 10 version 22H2
2. Open Firefox settings or any UI menu

Actual results:

• Large portions of text throughout the Firefox UI displays as garbled characters/symbols, including tab titles, menus, and settings
• Web page content renders normally with correct fonts
• Rolling back to Firefox 147.0.1 resolves the issue and text displays correctly

Expected results:

• Firefox UI text should display properly using the system default font

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Settings UI' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jack Jones]

Attachment: Firefox 147.0.2 UI Font Messed Up - Settings (Home).jpg

Comment 3

[Jack Jones]

Attachment: Firefox 147.0.2 UI Font Messed Up - Tab Bar Text.jpg

Comment 4

[Gian-Carlo Pascutto [:gcp]]

Jack, does this problem disappear if you go back to a previous version? Or is it really a regression in 147?

Ah, I see: "Rolling back to Firefox 147.0.1 resolves the issue and text displays correctly"

Comment 5

[Gian-Carlo Pascutto [:gcp]]

The icons in your screenshot 2 don't match current Firefox, some of them are much older. Is it possible you have some extensive customization to the UI applied somewhere that is now broken?

Comment 6

[Jack Jones]

Attachment: Firefox 147.0.2 UI Font Messed Up - Settings (General) (No Customizations - Default Dark Theme).jpg

Comment 7

[Jack Jones]

Attachment: Firefox 147.0.2 UI Font Messed Up - Settings (Home) (No Customizations - Default Dark Theme).jpg

Comment 8

[Jack Jones]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #5)

The icons in your screenshot 2 don't match current Firefox, some of them are much older. Is it possible you have some extensive customization to the UI applied somewhere that is now broken?

I have performed a clean test to rule out local customizations:

• Custom CSS: I previously had Custom CSS tweaks for Firefox installed. I have since removed all of it, but the issue persists on version 147.0.2.
• Themes: I have reverted to the default Firefox dark theme.
• Troubleshooting Mode: Starting Firefox with all extensions disabled (Troubleshooting Mode) does not resolve the issue.
• Regression: The UI displays correctly on 147.0.1 but breaks immediately upon updating to 147.0.2.

I have marked my previous screenshots as obsolete and attached new ones (taken after removing all customizations) for comparison.

Comment 9

[Jack Jones]

I have completed further troubleshooting that points to a specific regression in the shared rendering engine of Firefox and Thunderbird. Notably, my Thunderbird install updated today (January 28), one day after my Firefox updated, and it is now exhibiting the exact same garbled UI text issues.

Sequential Updates and Findings

• Firefox Version 147.0.2
  The update occurred yesterday and resulted in the UI text becoming garbled.
• Thunderbird Version 147.0.1
  The update from 147.0 occurred today and resulted in the UI text becoming garbled in the exact same manner.

System Font Isolation

I previously used Lato as my Windows system-level UI font. To test the root cause, I changed the system font back to Segoe UI, which caused both Firefox and Thunderbird to render normally again.

I also tested with the font Inter. While almost all the main UI recovered, specific elements, such as the "Thunderbird is up to date" line in the About dialog, remain garbled.

Conclusion

This is not a failure of my local CSS or extensions. Because this behavior appeared in both Firefox and Thunderbird immediately following these respective version bumps, and because no other Windows applications are affected, there is a clear regression in how the Mozilla platform handles third-party system fonts. The rendering engine has lost compatibility with fonts like Lato that functioned perfectly until this latest release cycle.

Comment 10

[Ryan VanderMeulen (PTO, back July 27)]

Looking at the pushlog between 147.0.1 and 147.0.2, the only change I see that looks potentially-related is bug 2009140, which changed Windows sandbox settings related to fonts. Maybe Bob has an idea for how to proceed.

Comment 11

[Gian-Carlo Pascutto [:gcp]]

That looks like it, especially as the first line diagnosis was "corrupted user font", which the reporter had successfully excluded as the cause.

Reading through that bug, the factor would be that OP has a lot of custom fonts installed outside the normal Windows directories, which causes us to have to add additional sandbox rules, until we run out of space. OP was near the limit and that fix pushed them over it. I read through the bugs but it's not clear to me if that space can be arbitrarily increased or if it's a Windows limit.

I'll confirm this and leave it to Bob :-)

Comment 12

[Jack Jones]

For additional context, here are some environmental details that may help isolate the root cause:

Font Management System

I use FontBase to manage custom fonts on Windows 10. The fonts mentioned in my testing (Lato and Inter) are installed system-wide and appear in both the standard Windows font directory (C:\Windows\Fonts) and FontBase's internal directories. I cannot definitively determine which file path the system references, though all applications outside of Firefox and Thunderbird render these fonts correctly.

Regression Confirmation

Both Firefox 147.0.1 and Thunderbird 147.0 (and prior versions) rendered these fonts perfectly with this exact FontBase configuration. Rolling back to those versions immediately resolves the garbled text issue, confirming this is a regression introduced in Firefox 147.0.2 and Thunderbird 147.0.1.

Isolation to Mozilla Platform

No other Windows applications exhibit this font rendering issue. The problem is isolated exclusively to these specific Firefox and Thunderbird version updates.

Comment 13

[Bob Owen (:bobowen)]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #11)

That looks like it, especially as the first line diagnosis was "corrupted user font", which the reporter had successfully excluded as the cause.

Reading through that bug, the factor would be that OP has a lot of custom fonts installed outside the normal Windows directories, which causes us to have to add additional sandbox rules, until we run out of space. OP was near the limit and that fix pushed them over it. I read through the bugs but it's not clear to me if that space can be arbitrarily increased or if it's a Windows limit.

I'll confirm this and leave it to Bob :-)

There's no Windows limit, it is limited because it will mean allocating that extra shared memory for every other sandboxed child.
I think that's probably worth it to make this issue even less likely.
This adds even more weight to the argument for bug 2002995.

Comment 14

[Bob Owen (:bobowen)]

Attachment: Bug 2012950 - Increase the number of sandbox policy memory pages. r=yjuglaret!

Comment 15

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=EI1_twmMREG7-uB2AZFqJw.0&revision=dc8fa5a2bd13a9041122c7b56f3e6451bcb98c2c

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ce12ba096df9
https://hg.mozilla.org/integration/autoland/rev/8cffecb3d0d0
Increase the number of sandbox policy memory pages. r=yjuglaret

Comment 17

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8cffecb3d0d0

Comment 18

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

The patch landed in nightly and beta is affected.
:bobowen, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox148 to wontfix.

For more information, please visit BugBot documentation.

Comment 19

[Ryan VanderMeulen (PTO, back July 27)]

Hi Jack, we've landed a change which will hopefully mitigate the issue. It's currently available in Nightly builds. Are you able to try that out to confirm that things are working better for you? We can look into expediting the fix to stable channels once we're confident that it helps without causing more issues.
https://www.firefox.com/channel/desktop/

Comment 20

[Jack Jones]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #19)

Hi Jack, we've landed a change which will hopefully mitigate the issue. It's currently available in Nightly builds. Are you able to try that out to confirm that things are working better for you? We can look into expediting the fix to stable channels once we're confident that it helps without causing more issues.
https://www.firefox.com/channel/desktop/

I tested Firefox Nightly (Portable) 149.0a1 - Build 20260130092147 (User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0), but unfortunately, the about:support and settings pages are still showing garbled text.

While investigating, I found a workaround that might help identify the root cause. I noticed I had multiple instances of Lato-Regular.ttf on my drive:

• C:\Windows\Fonts\Lato-Regular.ttf
• C:\Users\Jack\FontBase\Providers\Google\Lato-Regular.ttf (via FontBase)

After disabling and removing all activations of Lato except for the one in the default Windows font directory, Firefox 147.0.2, Nightly, and Thunderbird 147.0.1 all returned to normal and displayed fonts properly in all UI and page elements. It seems the issue is specific to how the updated Firefox handles system fonts when they are activated via FontBase or located in non-standard directories.

Since this only started happening in v147.0.2 and doesn't affect any of my other browsers or apps, is there a way to ensure Firefox remains compatible with fonts managed outside of the default directory? I've attached a screenshot of the garbled text in Firefox Nightly Portable for reference.

Comment 21

[Jack Jones]

Attachment: Firefox Nightly 149.0a1 (Build 20260130092147) - aboutːsupport - Garbled Text (Lato).jpg

Comment 22

[Jack Jones]

Correction to Comment 20:

I need to clarify my previous findings regarding the workaround. While disabling the FontBase instances of Lato resolved the issue for Firefox 147.0.2 and Nightly, it did not fix the issue for Thunderbird 147.0.1.

Even with only the default C:\Windows\Fonts\ instance active, Thunderbird is still showing garbled text. Specifically:

• The UI elements remain garbled.
• The message body text in Google emails is also affected, rendering them unreadable.

It appears the underlying font-handling regression persists in Thunderbird despite the local changes that helped Firefox.

Comment 23

[Bob Owen (:bobowen)]

(In reply to Jack Jones from comment #20)

Thanks for all your help testing this.

I tested Firefox Nightly (Portable) 149.0a1 - Build 20260130092147 (User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0), but unfortunately, the about:support and settings pages are still showing garbled text.

That's confusing, because there should be more room for font access rules in Nightly than there was in Fx147.0.1.
Do you have a large number of user fonts installed?

While investigating, I found a workaround that might help identify the root cause. I noticed I had multiple instances of Lato-Regular.ttf on my drive:

• C:\Windows\Fonts\Lato-Regular.ttf
• C:\Users\Jack\FontBase\Providers\Google\Lato-Regular.ttf (via FontBase)

After disabling and removing all activations of Lato except for the one in the default Windows font directory, Firefox 147.0.2, Nightly, and Thunderbird 147.0.1 all returned to normal and displayed fonts properly in all UI and page elements. It seems the issue is specific to how the updated Firefox handles system fonts when they are activated via FontBase or located in non-standard directories.

This makes sense it is the fonts installed in your Users directory that we have to give access to in the sandboxed GPU process.
I might have expected the GPU process to crash (for debugging purposes) on Nightly if it fails to find a font, but I don't think that it could have otherwise you would not have got the garbled fonts.
Do you have any crashes for today in the about:crashes page?
If you do, could you submit any unsubmitted ones and post links to them, please.

Comment 24

[Jack Jones]

(In reply to Bob Owen (:bobowen) from comment #23)

Do you have a large number of user fonts installed?

In my C:\Windows\Fonts\ directory, I have 493 fonts. Additionally, FontBase shows 212 "active" fonts. Since some of those active fonts overlap with what is already in the Windows font directory, I'm not sure what the exact total of unique fonts is or if that total is considered a normal or large number of fonts. Regardless, this setup functioned perfectly in Firefox 147.0.1.

Do you have any crashes for today in the about:crashes page?

No, there are no recent crashes listed in about:crashes. The most recent entry is from 2021, which is unrelated to this issue. Since the UI remains interactive despite the garbled text, it seems the GPU process is encountering a silent access/permission error rather than a hard crash.

Comment 25

[Bob Owen (:bobowen)]

(In reply to Jack Jones from comment #24)

(In reply to Bob Owen (:bobowen) from comment #23)

Do you have a large number of user fonts installed?

In my C:\Windows\Fonts\ directory, I have 493 fonts. Additionally, FontBase shows 212 "active" fonts. Since some of those active fonts overlap with what is already in the Windows font directory, I'm not sure what the exact total of unique fonts is or if that total is considered a normal or large number of fonts. Regardless, this setup functioned perfectly in Firefox 147.0.1.

Do you have any crashes for today in the about:crashes page?

No, there are no recent crashes listed in about:crashes. The most recent entry is from 2021, which is unrelated to this issue. Since the UI remains interactive despite the garbled text, it seems the GPU process is encountering a silent access/permission error rather than a hard crash.

OK, thanks again for the information.
I've filed bug 2013640 to fallback to a weaker setting if we don't have room for all of the user fonts.

Comment 26

[Bob Owen (:bobowen)]

Attachment: Bug 2012950 - Increase the number of sandbox policy memory pages.

We are seeing some users running out of rules space for fonts. This patch adds
another 32 KB of rules space to try and make sure we mitigate the issue
for most if not all users.
We will be moving to a single font rule in Bug 2002995, which will mean we can
reduce the kPolMemPageCount back to a much smaller number.

Original Revision: https://phabricator.services.mozilla.com/D280918

Comment 27

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: More users with large numbers of fonts will get garbled text if some fonts are used. This allow for more font sandbox policy rules.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Simple change to constant that defines the number of memory pages allowed for rules space.
• String changes made/needed: None
• Is Android affected?: no

Comment 28

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: More users with large numbers of fonts will get potential crashes or garbled text if some fonts are used. This allows for more font sandbox policy rules.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Simple change to constant that defines the number of memory pages allowed for rules space.
• String changes made/needed: None
• Is Android affected?: no

Comment 29

[Bob Owen (:bobowen)]

Attachment: Bug 2012950 - Increase the number of sandbox policy memory pages.

We are seeing some users running out of rules space for fonts. This patch adds
another 32 KB of rules space to try and make sure we mitigate the issue
for most if not all users.
We will be moving to a single font rule in Bug 2002995, which will mean we can
reduce the kPolMemPageCount back to a much smaller number.

Original Revision: https://phabricator.services.mozilla.com/D280918

Comment 30

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/545f356277f3
https://hg.mozilla.org/releases/mozilla-beta/rev/cc9f8f31e18e

Comment 31

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/76a5ee403300
https://hg.mozilla.org/releases/mozilla-release/rev/0555988ac268

Comment 32

[Ryan VanderMeulen (PTO, back July 27)]

Thanks for the report, Jack! We'll be shipping the fix from this bug in the 147.0.3 release scheduled to ship later this week.

In the interest of managing expectations, we already know from your testing in this bug that it won't solve the problem in all situations, but the more comprehensive fix will require more time for development and testing before we're confident in shipping it and we didn't want to hold back this improvement in the mean time. Bug 2013640 is where the follow-up work is happening if you want to follow along with that.

EDIT: Sorry, I only noticed now that you're already actively involved in that bug! 😅

Comment 33

[Jack Jones]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #32)

Thanks for the report, Jack! We'll be shipping the fix from this bug in the 147.0.3 release scheduled to ship later this week.

That's great news, and earlier than expected! Thanks for the update.

I've rolled back to 147.0.1 in the meantime. The Windows default font location workaround I thought was working in 147.0.2 still showed symptoms in random places, like the Violentmonkey edit page when FontBase was active.

Interestingly, I found a launch sequence that resolved the issue temporarily. Exit FontBase completely, open Firefox first, then start FontBase while Firefox is running. Even though both apps were open simultaneously in either scenario, this specific order eliminated the symptoms. Just a bit tedious to maintain consistently.

Looking forward to the official fix in 147.0.3!

Comment 34

[Ina Popescu, Desktop QA]

I'm not able to reproduce this issue in Firefox 147.0.2 on Windows 10. I've installed the fonts both in the Windows Fonts folder and in FontBase, including some duplicates, and I'm not seeing any UI display issues on my side. Could you please test this in the latest versions Nightly 149.0a1, Firefox 148.0b10 and Firefox 147.0.3 build to see if the issue still occurs? Thank you.

Comment 35

[Bob Owen (:bobowen)]

(In reply to Ina Popescu, Desktop QA from comment #34)

I'm not able to reproduce this issue in Firefox 147.0.2 on Windows 10. I've installed the fonts both in the Windows Fonts folder and in FontBase, including some duplicates, and I'm not seeing any UI display issues on my side. Could you please test this in the latest versions Nightly 149.0a1, Firefox 148.0b10 and Firefox 147.0.3 build to see if the issue still occurs? Thank you.

You would need to install a very large number of fonts and make sure one of those fonts is used and not in the rules.
This is difficult to predict and even then the order they return from the registry and get added to the font rules is not guaranteed, so there could be some intermittent nature to it.
This change didn't actually fix things for Jack (see comment 20) but bug 2013640 comment 4 has.

Comment 36

[Ina Popescu, Desktop QA]

(In reply to Bob Owen (:bobowen) from comment #35)

(In reply to Ina Popescu, Desktop QA from comment #34)

I'm not able to reproduce this issue in Firefox 147.0.2 on Windows 10. I've installed the fonts both in the Windows Fonts folder and in FontBase, including some duplicates, and I'm not seeing any UI display issues on my side. Could you please test this in the latest versions Nightly 149.0a1, Firefox 148.0b10 and Firefox 147.0.3 build to see if the issue still occurs? Thank you.

You would need to install a very large number of fonts and make sure one of those fonts is used and not in the rules.
This is difficult to predict and even then the order they return from the registry and get added to the font rules is not guaranteed, so there could be some intermittent nature to it.
This change didn't actually fix things for Jack (see comment 20) but bug 2013640 comment 4 has.

Thanks for clarifying this. I'm updating the flags accordingly.

Comment 37

[Jack Jones]

(In reply to Ina Popescu, Desktop QA from comment #34)

I'm not able to reproduce this issue in Firefox 147.0.2 on Windows 10. I've installed the fonts both in the Windows Fonts folder and in FontBase, including some duplicates, and I'm not seeing any UI display issues on my side. Could you please test this in the latest versions Nightly 149.0a1, Firefox 148.0b10 and Firefox 147.0.3 build to see if the issue still occurs? Thank you.

I tested Firefox 147.0.3 with my current setup. Everything's working fine now, and I'm not seeing the issue anymore. My environment's changed a bit since I first reported the bug, but 147.0.3 is clean.

I didn't want to revert my whole system just to double-check, so I tested Thunderbird 147.0.1 instead. It showed the same regression as Firefox 147.0.2 (Thunderbird 147.0 was fine, but 147.0.1 has the problem). The garbled fonts are still there in Thunderbird 147.0.1, especially in Google email messages. Same machine, same fonts, same font management setup, but Firefox 147.0.3 has no problems at all. Hoping this fix lands in the next Thunderbird point release soon as well.

Comment 38

[Ina Popescu, Desktop QA]

Thanks @Jack Jones for testing! Based on Comment 37, this issue is verified as fixed in Firefox 147.0.3, so I'm updating the flag accordingly.