User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Get macOS Monterey beta.
Open Firefox.

Actual results:

Font rendering of -apple-system font is cursed. It doesn't render different font weights and letterspacig is wrong. This happens both on the UI and CSS fonts on websites. This happens only on macOS Monterey, not in Big Sur or earlier versions.

Expected results:

Font weight should be properly displayed and letter spacing should be fine, not so stretched.

What model of Mac is this on? I believe we have some issues that are specific to the M1 Macs and Monterey.... would be good to confirm exactly what configuration is involved here. (FWIW, the font looks OK on my intel-based MacBook Pro running Monterey beta...)

(In reply to Jonathan Kew (:jfkthame) from comment #4)

What model of Mac is this on? I believe we have some issues that are specific to the M1 Macs and Monterey.... would be good to confirm exactly what configuration is involved here. (FWIW, the font looks OK on my intel-based MacBook Pro running Monterey beta...)

Mine is Intel based, 2019 16-inch Macbook Pro

Interesting - that's exactly what mine is (16" MBPro, 2019), but I'm not seeing the bad system font rendering here. Maybe different OS versions? I'm currently on "12.0 Beta (21A5506j)", but it looks like there's an update available -- I'll try installing that later and see if anything changes.

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

Interesting - that's exactly what mine is (16" MBPro, 2019), but I'm not seeing the bad system font rendering here. Maybe different OS versions? I'm currently on "12.0 Beta (21A5506j)", but it looks like there's an update available -- I'll try installing that later and see if anything changes.

I'm on 21A5522h, but have had this bug since beta 1 (didn't report earlier because thought it was a macOS thing, but we're getting close to final :O). Also made a restore and new install of the OS and the bad font rendering is still there. :O

This is really strange -- for comparison, here's how the Firefox menu looks for me.

I have the same issue starting from Beta 1 (right now reproduced on 21A5534d) on MacBook Pro (15-inch, 2016). See attached screenshots from Safari and Firefox 93 for https://sparkmailapp.com/pricing site.

Safari

Firefox

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit auto_nag documentation.

I do not see this problem on macOS Monterey Beta 21A5552a on an M1 Macbook Pro.

Still happens on final release of Monterrey, even did a new clean install to check.

Macbook air 2020 m1, just installed monterey update - can confirm that this terrible font rendering is here. Was using slightly outdated firefox, made sure to update to latest version and still looks terrible. I have m1 iMac whish I didn't update yet, so I can compare two interfaces side by side.

I get this problem too on Monterey

Comparison of the good font rendering to the bad/condensed rendering

This is probably the same issue with Thunderbird 91.2.1, too. Bad/condensed font rendering and e.g. unread mails are not highlighted with a bold font.

macOS Monterey (12.0.1) was released yesterday and I can confirm the issue with a 2018 Intel-based MacBook Pro. It's especially noticeable on GitHub (GitHub uses system fonts) where the font is very different compared to Chrome now and where it's no longer possible to see bold fonts (like in mentions). This issue did not exist before the macOS update (macOS 11.6).

And yes, I can also confirm the previous comment: new e-mails in Thunderbird are no longer highlighted with a bold font. It has probably the same cause.

mhhh. Mozilla and MacOS a ever comlicated thematic..

It is present with Macbook Pro 16 2019 with Firefox 93 on MacOS Monterey 12.0.1
Problem with some Sites and Firefox Fonts itself.

This is a really serious issue. I still haven't seen it on any of my machines but I will attempt a fresh install today.

I just upgraded to macOS Monterey and I got the issue. It's pretty terrible. I'm on Firefox Developer Edition 94.0b9 (64 bits), on an i5 Mac mini with an Intel UHD Graphics 630, on macOS 12.0.1 (21A559).

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1715898#c5 this problem exists only on non English systems. I changed my System Primary Language to English and it works. Then I changed it back to my language this Problem occurs again.

[Tracking Requested - why for this release]: Serious quality regression on new version of macOS

I have set my system language to German and can reproduce the bug now.

Could this be also considered to be uplifted to ESR? Thunderbird is also affected and would suffer of this problem until next ESR.

This is really bad on Thunderbird ESR. Not only has the font become incredibly small, but you can't tell unread emails from read ones apart. System language is German.

This has to do with font variation axis names, and CGFont and CTFont disagreeing about whether the axis names should be localized, it seems. We're not sure yet what exactly changed in macOS Monterey; it's possible that the system font didn't contain localized axis names in previous macOS versions.

Jonathan is working on a patch.

I checked the font with fonttools and it does not appear to contain the localized variation axes names.

The localization is happening here using the the default localized name:

  * frame #0: 0x00007ff8172670c8 CoreText`CopyDefaultLocalizedName(__CFString const*, __CFString const*, __CFArray const*, __CFString const**)
    frame #1: 0x00007ff8172c6b10 CoreText`CopyLocalizedFontNameInternal(CGFont*, CGFontNameTable*, int, __CFArray const*, __CFString const**, __CFString const*) + 1621
    frame #2: 0x00007ff8172c6d20 CoreText`CopyLocalizedFontName(CGFontNameTable*, int, __CFArray const*, __CFString const**, __CFString const*) + 34
    frame #3: 0x00007ff8173156ea CoreText`TBaseFont::CopyVariationAxesExternal() const + 356
    frame #4: 0x00007ff81725ed10 CoreText`CTFontCopyVariationAxes + 39

10.15 doesn't do the localization. I'm not sure about 11

The same for Cyrillic locale. The default font is too condensed (addressbar, search bar, Github, Wikipedia).
Found another confirmation here: https://www.reddit.com/r/firefox/comments/qfoxx1/macos_monterey_condensed_font_on_firefox_ui/

Depends on D129576

Comment on attachment 9247883 [details]
Bug 1732629 - [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel,mstange

Beta/Release Uplift Approval Request

• User impact if declined: Bad rendering of the macOS system font (and potentially other variable fonts) for users on macOS 12 Monterey, when the system language is non-English
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Run macOS 12.0 Monterey; set the primary system language (in macOS System Preferences / Language & Region panel) to a non-English language; launch Firefox and observe the system font (in menus, tab titles, New Tab page, etc).
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): This feels a little risky because the macOS APIs involved are not well documented (e.g. the Apple docs don't tell us what axis names Core Graphics expects; nor do they guarantee that Core Graphics and Core Text will expose the axes in the same order, although that seems to hold true in practice).

OTOH, if any of the modified code fails, the result will be no worse than it was without the patches: failure to apply the proper variation settings to some fonts, leading to ugly text rendering.

• String changes made/needed:

Backed out for causing build bustages.

Backout link: https://hg.mozilla.org/integration/autoland/rev/41f479cca4dd6b49d7652d2c4e6638399730da03

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=EGZQ1V9_QtehYYe3FwhK9A.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=d67d7024d557d7f915473d9c944852fdc9dcb821

Failure log:
https://treeherder.mozilla.org/logviewer?job_id=356199573&repo=autoland&lineNumber=20579
https://treeherder.mozilla.org/logviewer?job_id=356199539&repo=autoland&lineNumber=97

We can counteract a big part of the risk with extensive manual testing. We've encountered bugs in this area previously (bug 1201318, bug 1671660, bug 1672842, bug 1675185) so we have some idea of the things that could go wrong.

I think we should do the following checks, on the platforms: macOS 10.12 (Intel), macOS 10.13/10.14 (Intel), macOS 10.15 (Intel), macOS 11 (both Intel and M1), macOS 12 (both Intel and M1), and for both an English and a non-English system language:

• Make sure that the UI fonts look normal
• On 10.13 and and above, make sure variable fonts work:
  • The horse should be running: https://www.axis-praxis.org/playground/horse/
  • Dragging the slider on https://v-fonts.com/ should affect the text
• On 10.15 and above, dragging the slider on attachment 9185744 [details] should smoothly change the shape of the percent glyph, with no big step between 17 and 18

I've made a spreadsheet to track testing progress: https://docs.google.com/spreadsheets/d/1aa1Biu72rX0bFYnCi3JOB0NzE-GECkP08Qx56bR1mSA/edit#gid=0

Edit: We've done testing on all these platforms now and the results look good.

https://hg.mozilla.org/mozilla-central/rev/cc139b6131e4
https://hg.mozilla.org/mozilla-central/rev/bf3b8e872279
https://hg.mozilla.org/mozilla-central/rev/11e1be6ce402

Comment on attachment 9247883 [details]
Bug 1732629 - [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel,mstange

Not seeing any new macOS crashes on Nightly since this landed. Thanks for all the work verifying this fix yesterday. Approved for 94.0rc2.

https://hg.mozilla.org/releases/mozilla-release/rev/50c3c72ffca0
https://hg.mozilla.org/releases/mozilla-release/rev/5ba64e5b36d2

Comment on attachment 9247883 [details]
Bug 1732629 - [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel,mstange

Approved for 91.3esr.

https://hg.mozilla.org/releases/mozilla-esr91/rev/a2d58d88ad47
https://hg.mozilla.org/releases/mozilla-esr91/rev/6c16cf83f51f

QA - Please expand exploratory testing around this issue/font-rendering in the UI.

(In reply to Audrey Fischer from comment #48)

QA - Please expand exploratory testing around this issue/font-rendering in the UI.

QA finished the smoke testing around this font rendering problem. Our testing revealed no issue. Details can be found inside this document.

I can confirm, that the font now renders correctly again in Thunderbird 91 ESR on macOS 12.

Just to fill in a bit more background (thanks to Myles): the breakage here occurred because the Core Text API we're using (CTFontCopyVariationAxes) was fixed this year to return localized variation-axis names (as its documentation has always claimed); as Core Graphics only recognizes the non-localized ones, that led to the issue here.

Apparently there's a private interface CTFontCopyVariationAxesInternal that provides the non-localized names; webkit switched to this in https://trac.webkit.org/changeset/285318/webkit to avoid a performance regression in the case where they don't actually use the names. We could consider going that way as well, to avoid calling both CTFontCopyVariationAxes and CGFontCopyVariationAxes, although as it's not public API there's always the possibility it will break or disappear without notice in some future update.