Bug 248134 - Old emojis with variation selector do not use correct font sometimes
Summary: Old emojis with variation selector do not use correct font sometimes
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: Safari 16
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: BrowserCompat, InRadar
Depends on:
Blocks:
 
Reported: 2022-11-19 13:15 PST by i
Modified: 2022-11-26 13:16 PST (History)
3 users (show)

See Also:

Attachments
minimal case of the bug (721 bytes, text/html)
2022-11-19 13:15 PST, i 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description i 2022-11-19 13:15:34 PST 
Created attachment 463625 [details]
minimal case of the bug

Condition:

1. The emojis end with the variation selector (EFB88F), like ㊗️, ☀️, etc.
2. The webpage uses a font (web font) for emojis.
3. The emoji font is not the first in font-family (no emoji in the prior font).

Expected: the emoji are rendered with the emoji font.

Actual: the emoji are rendered with the system font.

The minimal case is attached. The bug can be reproduced on macOS and iOS with the latest Safari. Meanwhile, Chrome and Firefox on macOS work as expected.

There are two known workarounds:

1. Place the emoji font as the first font in font-family. However, it's a partial fix (see the attachment). And the emoji font I use contains digits, which causes all digits to become emojis.
2. Trim the variation selector from the emojis (becoming ㊗ and ☀). This completely fixes it, but before the font is loaded, these emojis are old-style and ugly.
Comment 1 Radar WebKit Bug Importer 2022-11-26 13:16:15 PST 
<rdar://problem/102683342>