[Due for payment 2026-02-27] [$500] macOS Safari - Conversation - digit:emoji: displays corrupted characters in Safari

[mitarachim]

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: v9.2.61-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176722/test-cases/41237017
Email or phone of affected tester (no customers): pater.jarek+32@gmail.com
Issue reported by: Applause Internal Team
Device used: macOS 26.1 Safari
App Component: Chat Report View

Action Performed:

1. In Safari web browser go to staging.new.expensify.com
2. Go to any conversation
3. In the compose box, type any digit
4. Without typing a space, either type an emoji shortcode (e.g. 😄), or choose an emoji from the emoji picker
5. Send the message

Expected Result:

User is able to type a digit followed by an emoji without a space, and the message displays correctly.

Actual Result:

In Safari web browser, typing a digit in the compose box and inserting an emoji without a space results in corrupted characters.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7008784_1763592131019.issue.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021991898043177542270
• Upwork Job ID: 1991898043177542270
• Last Price Increase: 2026-03-04

[melvin-bot]

Triggered auto assignment to @heyjennahay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021991898043177542270

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Krishna2323 (External)

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2025-11-25 16:08:25 UTC.

Proposal

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

In Safari web browser, when a user types a digit (e.g., "1", "234") in the compose box and immediately adds an emoji without a space (either by typing an emoji shortcode like :smile: or selecting from the emoji picker), the resulting message displays corrupted or incorrectly joined characters. For example, typing "234:smile:" should display as "234😄" but instead shows corrupted characters in Safari.

This issue only occurs in Safari and does not affect Chrome, Firefox, or other browsers.

What is the root cause of that problem?

Safari has a browser-specific behavior where it automatically converts a digit immediately followed by an emoji into a Unicode keycap sequence (e.g., "1" + "😄" becomes "1️⃣"). This happens at the browser's input handling level before React can process the text. When the user types a digit and then inserts an emoji (via shortcode or picker), Safari's internal text processing tries to create these keycap sequences, causing character corruption or unexpected joining.

The issue occurs because:

1. Safari's input handling detects digit + emoji patterns
2. It attempts to create keycap emoji sequences automatically
3. This happens before our emoji conversion logic can normalize the text
4. The resulting Unicode sequence is malformed or corrupted

References supporting the root cause:

1. Unicode Keycap Sequences: Unicode Standard defines keycap sequences using the Combining Enclosing Keycap character (U+20E3) which combines with base characters (like digits) to form keycap emojis (e.g., "1" + U+20E3 = "1️⃣"). Safari's text input handling automatically attempts to create these sequences when it detects digit + emoji patterns. (Unicode Standard - Emoji)

2. Zero-Width Non-Joiner (ZWNJ): The ZWNJ character (U+200C) is a non-printing Unicode character specifically designed to prevent the formation of ligatures or unwanted character joining. It is commonly used in scripts that feature connected letter forms and can be applied to prevent automatic character combination in text rendering engines. (Wikipedia - Zero-width non-joiner)

3. Safari/WebKit Input Handling: Safari uses WebKit's text input processing which has been documented to have issues with automatic Unicode sequence formation, particularly with emoji and combining characters. The browser's input handling layer processes text before React/JavaScript can intercept it, leading to automatic keycap sequence attempts. (WebKit Bug Reports)

4. Known Safari Emoji Rendering Issues: Safari has exhibited various rendering inconsistencies with emoji sequences, especially when combined with other Unicode characters. The automatic keycap sequence behavior is a known Safari-specific quirk that differs from Chrome and Firefox. (GitHub Issues - Safari Emoji Rendering)

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

Insert a zero-width non-joiner (ZWNJ) character between digits and emojis after emoji shortcodes have been converted to Unicode emojis. This breaks Safari's automatic keycap sequence detection.

Code Changes

File: App/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.tsx

1. Add helper function to insert ZWNJ between digits and emojis:

// Insert ZWNJ between digits and emoji to prevent Safari keycap bug
function insertZWNJBetweenDigitAndEmoji(input: string) {
    return input.replace(/(\d)([\u{1F300}-\u{1FAFF}\u{1F000}-\u{1F9FF}\u2600-\u27BF])/gu, '$1\u200C$2');
}

2. Apply normalization in updateComment function after emoji conversion:

const updateComment = useCallback(
    (commentValue: string, shouldDebounceSaveComment?: boolean) => {
        // ... existing code ...
        
        // Emoji conversion first
        const {text: emojiConvertedText, emojis, cursorPosition} = replaceAndExtractEmojis(commentWithSpaceInserted, preferredSkinTone, preferredLocale);

        // Safari ZWNJ normalization AFTER shortcodes replaced, so 234:smile: → 234😄 (with ZWNJ)
        const newComment = insertZWNJBetweenDigitAndEmoji(emojiConvertedText);
        
        // ... rest of existing code using newComment ...
    },
    [/* dependencies */],
);

The key change is moving the normalization to occur after replaceAndExtractEmojis converts shortcodes like :smile: to Unicode emojis, ensuring the regex can properly detect digit + emoji patterns.

The fix should be applied in the updateComment function in ComposerWithSuggestions.tsx, specifically:

1. After emoji shortcodes (like :smile:) are converted to Unicode emojis via replaceAndExtractEmojis
2. Before the final text is saved to state
3. Use a regex pattern to detect digit + emoji sequences and insert ZWNJ (\u200C) between them

What alternative solutions did you explore? (Optional)

N/A

demo Video

on Safari browser

Screen.Recording.2025-11-25.at.9.09.55.PM.mov

on Chrome browser

Screen.Recording.2025-11-25.at.9.10.58.PM.mov

[Krishna2323]

Will review the proposal tomorrow.