1721223 - Unicode Subscript S (U+209B) does not render

Status: VERIFIED FIXED

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

Description

[simonbyrne]

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

Steps to reproduce:

Visit https://www.compart.com/en/unicode/U+209B

Actual results:

I see a place-holder character

Expected results:

See a subscript s character

Comment 1

[simonbyrne]

I should say that it renders correctly in both Chrome and Safari.

Comment 2

[Timea Cernea [:tbabos][inactive]]

Can also confirm this issue on all the latest Firefox versions on MacOS 10.15. Thanks for the report!

Comment 3

[Jonathan Kew [:jfkthame]]

Interesting -- it appears the only standard font present on macOS that includes this character is the hidden "system font", which is not used as part of our global font fallback search, which only considers "user-visible" fonts.

Adding -apple-system to the font-family list (e.g. using the Element Inspector) makes the character appear as expected.

We should allow the system font to be used during fallback as well. (This may be slightly tricky because there are other "hidden" fonts that we don't want fallback using, such as LastResort.)

Comment 4

[Jonathan Kew [:jfkthame]]

Investigating this a bit, it turns out that it fails because when gfxMacPlatformFontList::PlatformGlobalFontFallback uses Core Text to determine how to render this character, it (correctly) chooses the .SFNS Text system font; but that family is missing from the global list we got from CTFontManagerCopyAvailableFontFamilyNames. In InitSystemFontNames we work around this by creating an old-style gfxFontFamily for it, but PlatformGlobalFontFallback doesn't look for that, and so it bails out without returning a usable font.

Fixing PlatformGlobalFontFallback to check for the (unshared) system font-family entry if it doesn't find the expected font in the shared list resolves the problem here, so that we get the desired fallback rendering.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1721223 - Ensure platform font fallback can find the macOS system font, even though it is omitted from the shared font list. r=lsalzman

Comment 6

[Jonathan Kew [:jfkthame]]

Hmm, the reftest there passes for me locally (on Big Sur), but fails on tryserver (running Catalina). I guess it has an older version of the system font that doesn't support U+209B yet.

I'll see if there's some other character that may be better for testing this.

Comment 7

[Jonathan Kew [:jfkthame]]

Yep - https://apple.stackexchange.com/questions/396864/why-cant-i-see-subscript-s-unicode-character-ₛ-u209b-even-though-i-can appears to confirm that U+209B was not supported by the standard fonts on 10.15, so that's why the test failed on try.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/373f5a7f296b
Ensure platform font fallback can find the macOS system font, even though it is omitted from the shared font list. r=lsalzman

Comment 9

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/373f5a7f296b

Comment 10

[Ciprian Georgiu, Desktop QA]

I've reproduced this bug using an affected Nightly build 2021-07-19, with the steps from comment 0.

The bug is verified as fixed on macOS 11, with Beta 92.0b2.