1672842 - System fonts render incorrectly on Big Sur when compiling with the 10.13 SDK or newer

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Markus Stange [:mstange]]

System fonts are rendered with Helvetica instead of San Francisco when building with modern SDKs. Moreover, during startup, these messages are printed:

2020-10-22 17:03:34.455 firefox[83998:4623540] CoreText note: Client requested name ".SFNS-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
2020-10-22 17:03:34.455 firefox[83998:4623540] CoreText note: Set a breakpoint on CTFontLogSystemFontNameRequest to debug.

This does not happen when building with the 10.11 SDK, probably thanks to a compatibility hack. I don't know which SDK this starts happening on. (edit: Alexei tested, it starts with the 10.13 SDK.)

When building with SDK	and running on OS	Do system fonts look correct?
10.11	macOS 10.15	yes
10.11 or 10.12	macOS 11.0	yes
10.13 - 11.0	macOS 11.0	no

We hit CTFontLogSystemFontNameRequest at the following stack:

* thread #1, name = 'MainThread', queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0: 0x00007fff21a9ba8b CoreText`CTFontLogSystemFontNameRequest
    frame #1: 0x00007fff21a99ecd CoreText`TDescriptorSource::CopyFontDescriptorPerPostScriptName(__CFString const*, unsigned long, unsigned long, __CFString const*, __CFNumber const*, CTFontLegibilityWeight, __CFBoolean const*) const + 93
    frame #2: 0x00007fff219ca204 CoreText`TDescriptor::CreateMatchingDescriptorInternal(__CFSet const*, unsigned long) const + 2422
    frame #3: 0x00007fff219c946d CoreText`TDescriptor::CreateMatchingDescriptor(__CFSet const*, double, unsigned long) const + 191
    frame #4: 0x00007fff219c9384 CoreText`CTFontDescriptorCreateMatchingFontDescriptor + 41
    frame #5: 0x00007fff239d6ec5 UIFoundation`+[__NSFontTypefaceInfo typefaceInfoForPostscriptName:options:] + 318
    frame #6: 0x00007fff239d9b1e UIFoundation`__NSFontFactoryWithName + 136
    frame #7: 0x00007fff239d9a2d UIFoundation`+[NSFont fontWithName:size:] + 30
    frame #8: 0x0000000105b125ab XUL`gfxMacPlatformFontList::InitSystemFontNames() [inlined] GetRealFamilyName(aFont=<unavailable>) at gfxMacPlatformFontList.mm:1133:15 [opt]
    frame #9: 0x0000000105b12574 XUL`gfxMacPlatformFontList::InitSystemFontNames(this=0x0000000124c9d000) at gfxMacPlatformFontList.mm:1153 [opt]
    frame #10: 0x0000000105b12f6a XUL`gfxMacPlatformFontList::InitSharedFontListForPlatform(this=0x0000000124c9d000) at gfxMacPlatformFontList.mm:973:3 [opt]
    frame #11: 0x0000000105ae6b0b XUL`gfxPlatformFontList::InitFontList(this=0x0000000124c9d000) at gfxPlatformFontList.cpp:497:5 [opt]
    frame #12: 0x0000000105a9ff43 XUL`gfxPlatformMac::CreatePlatformFontList(this=<unavailable>) at gfxPlatformMac.cpp:108:7 [opt]
    frame #13: 0x0000000105a98248 XUL`gfxPlatform::Init() [inlined] gfxPlatformFontList::Init() at gfxPlatformFontList.h:175:33 [opt]
    frame #14: 0x0000000105a98224 XUL`gfxPlatform::Init() at gfxPlatform.cpp:991 [opt]
    frame #15: 0x0000000105a97490 XUL`gfxPlatform::GetPlatform() at gfxPlatform.cpp:510:5 [opt]
    frame #16: 0x000000010763f003 XUL`mozilla::widget::GfxInfoBase::GetContentBackend(this=<unavailable>, aContentBackend=u"") at GfxInfoBase.cpp:1780:25 [opt]
[...]

Fixing this is somewhat time-sensitive because building for Apple Silicon requires the Big Sur SDK.

Comment 1

[lolrepeatlol]

Attachment: Result of 10.13 SDK

Building with the 10.13 SDK also has this issue. I'll try building with the 10.12 SDK as well.

Comment 2

[lolrepeatlol]

Attachment: Result of 10.12 SDK

Building with the 10.12 SDK does not have this issue.

Comment 3

[Markus Stange [:mstange]]

Thanks for checking!

Comment 4

[lolrepeatlol]

(In reply to Markus Stange [:mstange] from comment #3)

Thanks for checking!

Of course! :)

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Jonathan, do you have feeling for how we'd fix this?

Comment 6

[Jonathan Kew [:jfkthame]]

I suspect we'll want to create a new subclass of gfxFontEntry (and family) records for the macOS system font(s), and handle them separately from the main font list where we rely on names as the primary identifiers of families & faces. We can no longer get away with looking up what (hidden) font name -apple-system needs to resolve to, and then treating it the same as a normal (user-visible) font. Likewise for font styles returned by the widget code for "native" look-and-feel: we can't use name-based font entries to track these any more.

An alternative form of font identification will need to be plumbed through to everywhere that fonts are handled/instantiated; e.g. we presumably won't be able to use the postscript name as the thing we serialize and send to webrender, as it will fail to resolve to the required font on the WR side.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

So one thing we'll need to be careful about is that once we use the proper UI CTFonts the glyph ids can change across different sizes. It seems like we're already careful to keep the fonts separate so we might be fine.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Jonathan, do you have time to work on this in the near term? I can fix up the webrender serialization stuff.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)

So one thing we'll need to be careful about is that once we use the proper UI CTFonts the glyph ids can change across different sizes. It seems like we're already careful to keep the fonts separate so we might be fine.

I think that shouldn't be a problem, as we instantiate gfxFonts and moz2d ScaledFonts separately per size. (Though we may have to be careful about the distinction between device-pixel size and Cocoa point size, given that in gfx we normally work with device-pixel sizes.)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #8)

Jonathan, do you have time to work on this in the near term? I can fix up the webrender serialization stuff.

I could try to start something within the next week or so, probably.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

FWIW, it is possible to create CGFonts using the postscript name so we might be able to kludge a workaround that way.

Comment 11

[Jonathan Kew [:jfkthame]]

Interesting -- and that works without complaint even on Big Sur? I wonder if that'll last...

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Haven't tried on Big Sur, but it does work on 10.15 where creating the CTFont directly fails.

Comment 13

[Pete Collins (MDG)]

Does anyone have any links to info on how to get rust up and running on aarch64-apple-darwin?
Any other info on how to get Firefox successfully built natively on Big Sur?
Thanks

Comment 14

[Pete Collins (MDG)]

Some Helpful Resources

As of today rls (rust language server) and rstfmt (rust formatter) are missing:
https://rust-lang.github.io/rustup-components-history/aarch64-apple-darwin.html

Rust tracking page:
https://github.com/rust-lang/rust/issues/73908

Homebrew tracking page:
https://github.com/Homebrew/brew/issues/7857

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Pete, this bug is specifically about system fonts on Big Sur. You're likely to get more useful responses in a different forum. Perhaps (#developers) on chat.mozilla.org.

Comment 16

[Pete Collins (MDG)]

Thanks
I'm surprised there isn't a meta bug tracking building Firefox on Big Sur.

Comment 17

[Jonathan Kew [:jfkthame]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)

Haven't tried on Big Sur, but it does work on 10.15 where creating the CTFont directly fails.

Hmm.... so it's easy enough to rewrite the GetRealFamilyName() function in gfxMacPlatformFontList (which is where the warnings during startup are coming from) such that it works again, by going via CoreGraphics and CoreText APIs instead of using [NSFont fontWithName]. This gives me the "expected" real family name for the UI font again (on 10.15, at least).

However, that's not enough, because it turns out that the system UI fonts no longer appear in any way in the array returned by CTFontManagerCopyAvailableFontFamilyNames, and so we don't have ".SF NS" (or any of the other "hidden" fonts) in our font list at all. So all our font-selection code etc just won't see it as an available possibility, under any family name.

So I think we can do a "quick & dirty" fix here that essentially restores the current behavior for the system font, by manually creating a font family record for it during initialization. I'll attach a couple of patches that seem to be working for me on 10.15; I haven't tested anything on Big Sur itself.

As a more correct, longer-term fix we should really move to using CTFontCreateUIFontForLanguage to instantiate fonts based on CTFontUIFontType constants (along with language codes, which we don't currently respect -- see also bug 1605605). This will require more extensive changes to support CTFontUIFontType+language as an alternative form of font identification throughout the code, from CSS font properties all the way through gfx to webrender.

Comment 18

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1672842 - patch 1 - Update handling of macOS system font to avoid Core Text failures when instantiating the system font. r=jrmuizel

With this patch, the system font seems to work OK again on 10.15 when building Firefox with SDK10.15,
provided webrender is disabled. We no longer trigger the Core Text error messages from InitSystemFontNames(),
and the proper system font is used.

(With webrender, we get garbage because it fails to instantiate the system font and renders "random" Times
glyphs instead.)

Comment 19

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1672842 - patch 2 - For the hidden system font on macOS, instantiate Core Text fonts from a native CGFont rather than via a descriptor. r=jrmuizel

To fix the rendering of the macOS system font via webrender, we could back out bug 1671034 and bug 1671660;
but this would presumably exacerbate the CGFont caching issues that we've been trying to fix.

As an alternative, this patch leaves the CTFontDescriptor path in place for "normal" fonts, and just
reverts to instantiating from the CGFont in the case of hidden system fonts, so as to minimize the impact.

Depends on D95453

Comment 20

[Jeff Muizelaar [:jrmuizel]]

Attachment: Bug 1672842. Avoid using the postscript name to create the CTFontDescriptor.

Instead create at CTFont and get the descriptor from it.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f12a78b2df33
patch 1 - Update handling of macOS system font to avoid Core Text failures when instantiating the system font. r=jrmuizel

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0db0e6a3f8f0
Avoid using the postscript name to create the CTFontDescriptor. r=jfkthame

Comment 23

[Gian-Carlo Pascutto [:gcp]]

This doesn't block Big Sur support itself because we use an older version in CI (AFAIK).

Comment 24

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/f12a78b2df33
https://hg.mozilla.org/mozilla-central/rev/0db0e6a3f8f0

Comment 25

[Phabricator Automation]

Comment on attachment 9185019 [details]
Bug 1672842 - patch 2 - For the hidden system font on macOS, instantiate Core Text fonts from a native CGFont rather than via a descriptor. r=jrmuizel

Revision D95454 was moved to bug 1675185. Setting attachment 9185019 [details] to obsolete.