1654470 - Firefox 78.0.2 fails to recognize some emojis with skin tones.

Status: RESOLVED FIXED

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

Description

[Dom Leonard]

Attachment: skin-tone-test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Firefox 7.0.2 fails to recognize some emojis with skin tones.

Emoji affected can be forced to render correctly by inserting V16 (render as emoji) as the second code point in their Unicode string - confirming resources exist to render the emoji - but the patched string is not cross-browser compatible.

Differences noted between between Firefox 7.0.2(32 bit) and 7.0.2(64 bit) versions:

● Under Windows 7 (win32), without the "Segoe UI Emoji" font installed, only emoji strings starting with
○ '\u270c' (victory hand),
○ '\u261d' (index pointing up) and
○ '\u270d' (writing hand)

followed by a skin tone failed to be recognized. All others were rendered correctly using TwemojiMozilla.ttf.

● Under Windows 10 (win64), with "Segoe UI Emoji" installed, all emoji in the test file failed recognition, even after removing "Segoe UI Emoji" from the "about:config>font.name-list.emoji" item.

Examples:
● person bouncing ball: medium skin tone (26f9-1f3fd)
● woman lifting weights: medium-dark skin tone (1f3cb-1f3fe-200d-2640-fe0f)

The attachment lists all emojis detected as having this problem under Windows 10.

Actual results:

Some Unicode "fully qualified" emoji strings are being rendered using multiple glyphs from "Segoe UI Symbol" font.

Expected results:

The emoji strings should be decoded and rendered as emoji. They are not missing from either "Segoe UI Emoji" or "Mozilla Twemoji" font files. The table of affected emoji rendered as expected in Chrome, Edge webkit and Opera when tested.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[u635660]

this is interesting hey reporter do you got any suggestions to fix this i might try to fix this myself

Comment 3

[Mats Palmgren (inactive)]

Works for me on Linux using 78.0.2 and Nightly, fwiw.

Comment 4

[Dom Leonard]

While I can't help with the code base, I managed to discover more about the problem since the last comment:

A Possible Workaround

Specifying a font family for emoji strings works around this bug in both 64 bit and 32 bit versions of Firefox.

Installing TwemojiMozilla.ttf in Windows fonts and testing in webkit browsers showed that "Twemoji Mozilla" and "Segoi UI Emoji" fonts are interchangeable and can be eliminated from investigation .

Basically the problem now is that some emoji with skin tones fail to be recognized when no emoji font family rule was specified in CSS - typical of pages relying on browsers to find a suitable font for them.

Thoughts

Searching Unicode's emoji-test.txt file reveals

• FE0F (with two spaces) may terminate a sequence of emoji code points but is not required to do so.
• FE0F 1F3FB, FE0F 1F3FC, FE0F 1F3FD, FE0F 1F3FE, FE0F 1F3FF (VS16 + skin component) never occur.

Hence treating `FE0F' followed by a skin tone component as the end of one emoji and the start of another should fix the patched string column content of the attachment.

By inspection, skin tone component values MUST be treated as implying "render as emoji" without the use of FEOF - because skin tone components can replace FE0F in code point sequences. Some case examples:

261D FE0F                                  ; fully-qualified     # ☝️ E0.6 index pointing up
261D 1F3FB                                 ; fully-qualified     # ☝🏻 E1.0 index pointing up: light skin tone
1F3CC FE0F 200D 2642 FE0F                  ; fully-qualified     # 🏌️‍♂️ E4.0 man golfing
1F3CC 1F3FB 200D 2642 FE0F                 ; fully-qualified     # 🏌🏻‍♂️ E4.0 man golfing: light skin tone

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It might be informative to know what font is being used for the emoji when things don't work correctly versus what font is used when they do. You should be able to find this out by opening the developer tools ("devtools") inspector (Tools -> Web Developer -> Inspector) and looking at the Fonts panel while inspecting the relevant element in the DOM tree.

Comment 6

[Dom Leonard]

In win32 the emoji font was "Twemoji Mozilla" - the system does not have "Segoe UI Emoji" installed.

In win64 the emoji font used in the test file (which has not font-family specification) was

• "Segoe UI Symbol" for b/w glyphs in the "Unicode string" column,
• "Segoe UI Emoji" for colored emoji in the "Patched" column.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1654470 - Improve font selection heuristics for character sequences that should get emoji-style presentation. r=m_kato

Comment 8

[Jonathan Kew [:jfkthame]]

With the above patch, I get the same rendering on Win10 for both the "Unicode string" and "Patched" columns in the reporter's testcase -- color-emoji glyphs in both cases.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dbc142362607
Improve font selection heuristics for character sequences that should get emoji-style presentation. r=m_kato

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/dbc142362607