1965185 - Keycap emojis are not rendered correctly

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Calin Tanase]

Attachment: FF vs Chrome.png

Environment:
Operating system: Windows 11
Firefox version: 139/140

Steps to reproduce:

1. Go to https://www.google.com/search?client=firefox-b-1-d&q=9%EF%B8%8F%E2%83%A3
2. Observe the emoji in the search bar and links.

Expected Behavior:
The emoji is rendered.

Actual Behavior:
The emoji is not rendered.

Notes:

1. Does not reproduce on Windows 10
2. Does not reproduce on Firefox Release (138)
3. Not reproducible on Chrome

Comment 1

[Jonathan Kew [:jfkthame]]

This looks like bug 1963436, where a fix just landed -- can you confirm if you still see the issue in the latest Nightly?

Comment 2

[Alice0775 White]

I can reproduce the issue on Nightly140.0a1(20250507164202) Windows11.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c17bda78c329a8ed6a6820618769e3e6e91fff70&tochange=607af81ae4a206faf67e058bc6a1a9a37c532494

The bad build: Both the search field and the search results are fine.
The bad build: Emojis are not displayed correctly in both the search field and search result text.

And Bug 1963436 does not seem to fix this bug.

Comment 3

[Calin Tanase]

Attachment: Nightly Win 11.png

Still reproducible on Windows 11 with Nightly 140.0a1 (2025-05-07). On Windows 10 works fine.

Comment 4

[Jonathan Kew [:jfkthame]]

Ugh, must be affected by a difference between win10 and win11 fonts, I guess. Thanks, will try to investigate.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1955672

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: screenshot from Nightly 2025-05-07 on Win11 24H2

Strange, this doesn't seem to reproduce on my Windows 11 machine; see screenshot. For me it looks like bug 1963436 did resolve this (it was broken before I allowed my Nightly to update itself).

For those who are seeing this problem, could you please Inspect one of the problematic search results, and confirm what the Inspector shows for (a) the computed value of font-family, and (b) the fonts actually being used by the element. Thanks!

Comment 7

[Jonathan Kew [:jfkthame]]

ni? for the question in comment 6, as I am still unable to reproduce this locally.

Comment 8

[Alice0775 White]

Tested, Windows11 24H2.

• Firefox 138.0.1 --- Good
  (a) font-family: Arial, sans-serif from Computed
  (b) Segoe UI Emoji fonts inspector

• Firefox 134.0b5 and Nightly140.0a1(20250508215032) --- Bad
  (a) font-family: Arial, sans-serif from Computed
  (b) Arial / Meiryo from fonts inspector

Comment 9

[Jonathan Kew [:jfkthame]]

Thanks!

I figured out why I couldn't reproduce this: I had Noto Color Emoji installed on my Windows machine, and it gets successfully chosen for these emoji. With that font removed, I can now reproduce the issue: we're failing to use Segoe UI Emoji for keycap 1-9 sequences.

I have an idea why this is probably happening; will try to confirm the issue, and figure out how we can address it.

Comment 10

[Jonathan Kew [:jfkthame]]

OK, the key difference between Segoe UI Emoji (which fails) and Noto Color Emoji (which succeeds) is that the Noto font provides color glyphs for the digits by themselves (appropriate for use when the digit codepoint is followed by the emoji-style variation code U+FE0F), whereas Segoe UI Emoji doesn't; it only provides glyphs for the combination with U+20E3 to form a keycap.

The problem is that during font matching, we consider the digit codepoint and its associated variation selector, which explicitly calls for an emoji-style digit (before the combining keycap box is considered at all), and then reject Segoe UI Emoji because it doesn't provide a color glyph for this codepoint.

Digging in to Segoe UI Emoji, its cmap table includes a format-14 subtable that claims support for the <digit, VS16> sequences as the default form for those codepoints. As such, I think we should accept it as a valid font for the explicit variation sequences, even though it doesn't actually have color glyphs for them unless they're followed by the keycap codepoint.

Comment 11

[Donal Meehan [:dmeehan]]

We are in the final week of beta for Fx139, with only 2 beta builds left.
:jfkthame, re: Comment 10, do you plan on having a fix in time for Fx139?

Comment 12

[Jonathan Kew [:jfkthame]]

Yes, I have a patch that I'm just finalizing, hope to be ready to land very shortly.

Comment 13

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1965185 - Check for variation sequences supported as default-UVS entries in the cmap. r=#gfx-reviewers

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b37c916a073f
Check for variation sequences supported as default-UVS entries in the cmap. r=gfx-reviewers,lsalzman

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/48b7067c6ae6
Revert "Bug 1965185 - Check for variation sequences supported as default-UVS entries in the cmap. r=gfx-reviewers,lsalzman" as requested by Jonathan.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3510f1f9e979
Check for variation sequences supported as default-UVS entries in the cmap. r=gfx-reviewers,lsalzman

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/24a78092030d
Revert "Bug 1965185 - Check for variation sequences supported as default-UVS entries in the cmap. r=gfx-reviewers,lsalzman" for causing mochitests failures in browser_test_clipboardcache.js.

Comment 18

[Serban Stanca [:SerbanS]]

Backed out for causing mochitests failures in browser_test_clipboardcache.js.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | widget/tests/browser/browser_test_clipboardcache.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -

Comment 19

[Jonathan Kew [:jfkthame]]

Ugh, there's no obvious reason that test should've been affected, and it's a tsan-only timeout: I guess it must have been on the brink of hitting the timeout already, and just tipped over the line. Yeah...checking some logs from before the failure started, the browser_test_clipboardcache.js test is consistently taking over 100 seconds in tsan jobs. Giving it an increased timeout should avoid the issue.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1a0045726919
Check for variation sequences supported as default-UVS entries in the cmap. r=gfx-reviewers,lsalzman

Comment 21

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/1a0045726919

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.

Comment 23

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1965185 - Check for variation sequences supported as default-UVS entries in the cmap. r=#gfx-reviewers

Original Revision: https://phabricator.services.mozilla.com/D248935

Comment 24

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: keycap emojis broken on some pages
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: (see comment 0)
• Risk associated with taking this patch: low
• Explanation of risk level: only affects font selection when variation-selector codepoints are present
• String changes made/needed: none
• Is Android affected?: yes

Comment 25

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/e75adc195e78