Open Bug 1845450 Opened 1 year ago Updated 1 year ago

Firefox forcibly render emoji ZWJ sequences in default color emoji regardless of custom font-family


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

Firefox 116





(Reporter: reinhart_previano, Unassigned)



(1 file)

When setting a custom CSS font-family attribute like font-family: "Noto Emoji", Tofu; for outlined (non-color) emojis, Firefox still renders ZWJ-based emojis using the systemʼs color emoji instead of the outlined one.

This behavior is, at least, confirmed on Firefox for Android as well as Firefox for macOS. This is not reproducible in Chrome and Safari.

An example can be found on, under the Outlined column examples.

Firefox specifically chooses to use a color-emoji font, even if the CSS font-family property specifies a monochrome font that includes the relevant codepoints, in several cases:

(a) when Variation Selector 16 is present in the text
(b) for regional-indicator code pairs (flags)
(c) when a skin-tone modifier code is present

This is on the basis that (a) VS16 explicitly requests "emoji-style" rather than "text-style" presentation, and (b, c) flags and skin-tone modifiers generally can't be rendered in a meaningful way by monochrome fonts.

I see that Noto Emoji does handle the regional-indicator codes, by displaying the letters rather than actual flag graphics; arguably that's a reasonable representation. (Though I suspect most users think of the flags as being the primary symbols, and in many cases might not recognize what the two-letter codes represent. There have been complaints in the past about the flags failing to render on Windows, because Segoe UI Emoji doesn't support them but just displays the letter codes.)

As for the skin-tone modifiers, Noto Emoji seems to ignore them completely, which means significant information loss is happening in that rendering.

In cases where style information specifies a monochrome-only font, but the content includes the U+FE0F variation selector that explicitly calls for emoji-style rendering, it seems to me there's a fundamental conflict, and it's unclear which should take priority: the styling data, or the Unicode text?

So.... all this seems quite difficult to resolve; I don't think there's any single algorithm that will satisfy everyone in all cases. There may of course be scope to refine the font-selection heuristics we're using, but it's not as simple as it looks.

Severity: -- → S4
You need to log in before you can comment on or make changes to this bug.