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

Steps to reproduce:

Updated firefox to 89 in Win7 with UAC disabled.

Actual results:

All my fonts look wrong

Expected results:

Fonts look same as before.

FontSubstitutes registry entry is not being respected.

Disabling gfx.e10s.font-list.shared works around the problem.

It's discussed here a little bit
https://www.reddit.com/r/firefox/comments/nq19es/windows_firefox_89_apparently_not_honoring/

Seems weird that this tech could create so many different issues, but I guess that's why it was in testing for so long. Does it entail a massively rewritten font database which needed to be debugged as long as the original font database?

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 revert this change in case you think the bot is wrong.

Thanks for filing this. Yes, the behavior has changed: previously, FontSubstitutes were applied "eagerly", so that when a given font name is requested (e.g. by the CSS in a page), Firefox would check for a FontSubstitute entry for that name before attempting to look up the original font. So substitutes always got used. The new code first looks for the font exactly as requested, and only falls back to checking FontSubstitutes if the original isn't available.

It's not entirely clear to me which behavior is "correct" here; I think it could be argued either way. At https://docs.microsoft.com/en-us/globalization/input/font-technology there is a brief section about "Font Substitution", which says that:

Font substitution is implemented by an application to replace a request for a font that is not available into one that is available.

To me this suggests that Firefox's new behavior is correct: substitution is performed only if the requested font is not available. This also matches how other browsers and applications handle things, according to the discussion I've seen.

However, I can see that the change may be frustrating for users who have been deliberatly using registry FontSubstitutes entries to "globally" replace a font, such as swapping the Segoe UI system font for something else, or who have unknowingly relying on default substitutes such as Helvetica->Arial, which meant that installing a "broken" Helvetica family such as a single, compressed face would essentially be ignored rather than start showing up on web pages.

Given that the updated behavior better matches other browsers, I am reluctant to simply revert it; in general, interoperability is more helpful than having each application interpret the system font configuration in its own unique way. But maybe we can implement an option to enable "eager" substitutions for those users who prefer it. I'll try to look into the possibilities.

(See also bug 1714197, where the original reported issue is a result of this change, though people then started adding comments on other font-related issues as well.)

The proposed patch here creates a new about:config setting gfx.windows-font-substitutes.always, with the default value false giving the "new" behavior where substitutes are only used if the original requested font is not available. Changing this setting to true will bring back the old behavior of unconditionally applying the substitutions.

Set release status flags based on info from the regressing bug 1694174

Thank you for this patch and for explaining what's going on. I acknowledge this doesn't seem to be the way FontSubstitutes is meant to be used. But it's really valuable for accessibility reasons to have that feature and windows doesn't really have it anywhere else. So, if you wanted to keep FontSubstitutes behaving in a standard way, one option would be to add that functionality into a different option: there are some fiddly issues if you're not careful with designing the syntax, but you could have an option that lists the replacements, for example: "Segoe UI:Tahoma;Helvetica:Arial". I don't think anyone desperate enough for this functionality would complain too much about having to do it that way. We're mainly interested in preventing the assault of our eyeballs, one way or another. I don't really expect you to like that idea, but I figure I ought to at least offer something myself.

https://hg.mozilla.org/mozilla-central/rev/e25163f7afd3

Comment on attachment 9227157 [details]
Bug 1716433 - Create a pref to determine whether Windows font substitutes are applied always, or only as fallback for unavailable fonts. r=lsalzman

Beta/Release Uplift Approval Request

• User impact if declined: Bug 1694174 (now disabled for 89.0.1, but coming back in 90...) changed behavior of "font substitutions" on Windows. The new behavior is arguably more "correct", but some users prefer the older version, and the change disrupts their font choices.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): No change to the new default behavior; this just adds a (Windows-only) about:config pref to allow users to opt back in to the previous behavior.
• String changes made/needed:

Bug 1694174 was backed out on the release channel which fixes this regression in the just released 89.0.1 version.

Comment on attachment 9227157 [details]
Bug 1716433 - Create a pref to determine whether Windows font substitutes are applied always, or only as fallback for unavailable fonts. r=lsalzman

approved for 90.0b9

https://hg.mozilla.org/releases/mozilla-beta/rev/fcfe4fb4efe8