[Due for payment 2026-07-02] Web - Picker - Some emojis are displayed with arrow icons behind them on emoji picker.

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93595
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Click on emoji picker.
4. Note that "upside_down_face" and "head_shaking_vertically" emojis are displayed overlapping blue arrow icons.

Expected Result:

All emojis should be correctly visible on emoji picker and none of them should be overlapped with different icons.

Actual Result:

"Upside_down_face" and "head_shaking_vertically" emojis are displayed with blue arrow icons behind them on emoji picker.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7188173_1782180755738.Emojis.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7188173

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/5f32784a9c7e14e3c7a1021a981060590da961d19051f22dd7f0e992e7b81037

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #93595

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Windows / Chrome, the two new "head shaking" emojis added by #93595 render as a slightly-smiling face next to a separate blue arrow icon instead of as a single combined emoji. (The report names "upside_down_face", but the affected emojis are actually head_shaking_horizontally and head_shaking_vertically — the base glyph 🙂 is easy to mistake for 🙃.)

What is the root cause of that problem?

The new emojis are Unicode 15.1 ZWJ sequences, not single code points:

• head_shaking_horizontally → 1F642 200D 2194 FE0F (🙂 + ZWJ + ↔️)
• head_shaking_vertically → 1F642 200D 2195 FE0F (🙂 + ZWJ + ↕️)

See assets/emojis/common.ts:91-100.

On Windows, the app does not use the OS emoji font — it bundles a pinned copy of Segoe UI Emoji as Windows Segoe UI Emoji (assets/css/fonts.css:71-79), which is forced ahead of the other emoji fonts in the cascade (multiFontFamily/index.ts:74-78).

That bundled seguiemj.ttf predates Unicode 15.1, so it has no ligature for the combined sequence but does contain the individual 🙂 and ↔️/↕️ glyphs. When a font earlier in the cascade covers the component code points but not the full ZWJ ligature, Chrome decomposes the cluster and draws each component separately — producing "face + blue arrow" rather than one emoji. It never falls through to Custom Emoji Font/Noto Color Emoji because the components are already covered.

This is why it reproduces only on Windows (bundled stale font) and not on macOS/iOS/Android, where up-to-date native emoji fonts render the full sequence — matching the PR author's test platforms.

What changes do you think we should make in order to solve the problem?

This is a deploy blocker, so pick one:

1. Fastest unblock (recommended for the deploy): Remove the two head_shaking_* entries (and any other Unicode 15.1+ sequences from the PR that decompose on the bundled font) from assets/emojis/common.ts / en.ts / es.ts, or revert #93595.
2. Proper fix (follow-up): Update the bundled emoji font assets so the new sequences render as one glyph — either refresh seguiemj.ttf to a Segoe UI Emoji version that includes the 15.1 sequences, or add the combined-sequence ligatures to CustomEmojiWebFont.ttf and ensure that font is consulted ahead of the stale Segoe copy for these clusters.

⚠️ The proper fix is a binary font-asset update, not a clean code change — it should be handled by the PR author (shubham1206agra) or an internal engineer, ideally validated on Windows/Chrome.

What alternative solutions did you explore?

Verified this is not a sizing/overlap CSS bug: the "arrow" is a real fallback glyph from the decomposed ZWJ sequence, consistent with the Windows-only reproduction and the bundled-font cascade.

Investigation details

• Affected emojis are ZWJ sequences (1F642-200D-2194-FE0F, 1F642-200D-2195-FE0F), Unicode 15.1.
• Windows forces Windows Segoe UI Emoji (bundled /fonts/seguiemj.ttf) to the front of every emoji font family.
• Chrome's per-grapheme fallback: a cascade font that covers the component code points but not the ligature wins and renders the components separately.
• Not reproducible in production because the emojis are brand-new (added in this release).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR (note: the proper fix is a font-asset change — see the ⚠️ above).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.