User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

• Have a new clean profile to just make sure the history cache is clean.
• Go to a site that has emoji's in their title(my ex. https://github.com/privacytools/privacytools.io)
• Visit the site etc. Make sure it's now in the history cache.
• Relaunch the browser to that same profile.

Actual results:

Open up the search bar and notice that the emoji's of this https://github.com/privacytools/privacytools.io are not being rendered but their Unicode symbol actually is.

I'd like to note that when in your search bar this doesn't come up as suggested site because you've visited it recently in this case. And type pri... the first occurrence when this site is being shown as suggested site the emoji's aren't rendered as well but type 1 more letter into the sequence and you will see the emoji's are being rendered like expected.

^ That's why the bug title is "after second occurrence"

Expected results:

The emoji's are being rendered and not their unicode symbol on the first occurence.

If you go to about:config and set gfx.font_rendering.fallback.async to false for your test profile, does the issue still occur?

Nope, the issue then doesn't occur after gfx.font_rendering.fallback.async is being set to false

Jonathan, do you know how to proceed with this, given comment 2? Is this a regression from bug 1676966?

Yes, this comes from the change in bug 1676966, which means we don't block layout while trying to find a font that can render the emoji codepoint; instead, we reflow content once we've collected all the font data.

For web content, that would mean the rendering automatically gets updated after a moment or two, but I guess the currently-open search bar drop-down doesn't refresh, so you don't see the "fixed" rendering until it is closed and re-opened.

I'd consider this a relatively minor cosmetic issue, given that it resolves itself after a moment and then will stay "fixed" for the rest of the browser session. Still, it would be nice if we could avoid it. Maybe we should disable async fallback for the parent process, which is likely to be rendering UI where we really want to avoid even transiently-broken text (and we may not easily be able to refresh elements like open drop-downs), while leaving it enabled for web content.

The other thing we can do is add more "likely" fonts to the Common Fallbacks known in gfxPlatformGtk, so as to reduce the chance that we'll need to do a global search. In particular, on my Ubuntu machine "Noto Sans Symbols2" seems to be the place we should be looking for these characters, and it's not currently in our "common" list. So adding that would help.

Depends on D117666

https://hg.mozilla.org/mozilla-central/rev/bea1a638142c
https://hg.mozilla.org/mozilla-central/rev/d38df9a622df

Comment on attachment 9226854 [details]
Bug 1714762 - patch 1 - Don't use asynchronous font fallback in the parent process, to avoid glitches in UI rendering. r=lsalzman

Beta/Release Uplift Approval Request

• User impact if declined: Possibility that characters requiring font fallback (e.g. emoji) may not render correctly in UI (e.g. urlbar search results) when initially displayed.
• 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): Trivial patch to restore the original (synchronous) font-search behavior for the parent process, to ensure consistent rendering in the browser UI.
• String changes made/needed:

Comment on attachment 9226854 [details]
Bug 1714762 - patch 1 - Don't use asynchronous font fallback in the parent process, to avoid glitches in UI rendering. r=lsalzman

approved for 90.0b8

https://hg.mozilla.org/releases/mozilla-beta/rev/d84c7a35a171
https://hg.mozilla.org/releases/mozilla-beta/rev/79349f71d9e9