Affected versions

• Firefox 86.0a1

Affected platforms

• macOS 10.15.7

Steps to reproduce

1. Launch Firefox profile manager
2. Add an unicode profile, for example: ߂߃߄߅߆߇߈
3. Relaunch profile manager

Expected result

• The unicode profile is loaded instantly

Actual result

• The unicode profile shows some boxes, and after 2 seconds it "loads" itself

Regression range

• I will see for a regression

Additional notes

• The issue can be seen in the following attachment
• Windows and Ubuntu are not affected
• This issue may lead to a profile corruption

Jonathan, is this from the font changes in bug 1676966?

(In reply to Catalin Sasca, QA [:csasca] from comment #0)

• This issue may lead to a profile corruption

Why do you say this?

(In reply to Dave Townsend [:mossop] from comment #1)

Jonathan, is this from the font changes in bug 1676966?

Yes, it would be. The "߂߃߄߅߆߇߈" characters aren't supported by the default system fonts, so we do a font fallback search to try and render them, and since bug 1676966 we no longer block rendering on that search; instead we refresh once it completes.

In practice, I doubt very many users have N'ko profile names. :)

I don't think this introduces any risk of corruption; it's purely a visual issue.

Although there is a small probability that users will use N'ko profiles, I was suspecting this could be a profile corruption issue, not a rendering one.

One thing we can do that will fix this particular case (though not every possible example of using "unusual" Unicode characters) is to add more of the Noto fonts that Apple now ships to the "common fallbacks" list, so that they're found without hitting the global fallback codepath.

(It's a bit weird, actually, as Font Book doesn't show Noto Sans Nko -- or many others of the Noto fonts -- as being present at all; but on checking, it's there in /System/Library/Fonts/Supplemental/, and indeed gets used by both Safari and Firefox here.)

What I think we should do here, to take advantage of a lot more of the fonts that macOS now ships (mostly Noto faces) for more obscure languages/scripts, is to rewrite gfxPlatformMac::GetCommonFallbackFonts to work primarily from the resolved script run of the text being processed, instead of the rather ad hoc assignment of fonts based on blocks of Unicode codepoints. That approach doesn't scale well to supporting the large number of separate scripts that now have appropriate fallback fonts available.

In the process of investigating this, I also found that there are some oddities about the macOS font APIs: in particular, whether the fonts shipped in /System/Library/Fonts/Supplemental/ are exposed by CTFontManagerCopyAvailableFontFamilyNames depends on what SDK version was used to build the application. With SDK 10.14, the "supplemental" fonts show up in the list; but when the exact same code is built with SDK 10.15, they're absent by default, and only appear in the list if they are explicitly activated using CTFontManagerRegisterFontsForURLs or similar API. So to ensure consistent results regardless of the SDK used to build, we should do that activation during startup (as we do on older OS versions where they're found under /Library/Application Support/).

Depends on D102820

https://hg.mozilla.org/mozilla-central/rev/f7fc57b92765
https://hg.mozilla.org/mozilla-central/rev/4d42ff607081

Backed out 2 changesets for causing Bug 1688804.
Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=success%2Cpending%2Crunning%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=os%2Cx%2C10.14%2Cwebrender%2Cdebug%2Cmochitests%2Ctest-macosx1014-64-qr%2Fdebug-mochitest-browser-chrome-e10s%2C&group_state=expanded&tochange=8071b6b58a60818abd28d3e2084df2825dedf364&fromchange=afb6bcdbdf4f7345d8b683ca7d3337fcebf27d81&selectedTaskRun=b4V-ak-5RvuDDCEAiz065g.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=327800630&repo=autoland&lineNumber=17222

Backout merged: https://hg.mozilla.org/mozilla-central/rev/9fb5965ccb41

I just did a new try run at https://treeherder.mozilla.org/jobs?repo=try&revision=6413a07a4bf27b2c2228b927228afc3d496dbff6 and was not able to reproduce the leak reported in bug 1688804 despite multiple retriggers. So I'm going to try re-landing this.

https://hg.mozilla.org/mozilla-central/rev/831b1df31101
https://hg.mozilla.org/mozilla-central/rev/c82598fe3c17

Verified this issue on Firefox 87.0 and 88.0a1 (2021-03-18).