iOS - Emoji - The emoji picker is not displayed after tapping the emoji selector

[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.3.84-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-34319/folder/13176687/41236665/1444112472?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 13 iOS 26.5
App Component: User Settings

Action Performed:

Test 1

1. Open the app
2. Navigate to Account settings > Profile
3. Tap on Status
4. Tap on the emoji selector

Test 2

1. Open the app
2. Navigate to any chat
3. Tap on the emoji icon

Expected Result:

The emoji picker is displayed

Actual Result:

The emoji picker is not displayed after tapping the emoji selector

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164662_1779924776924.ScreenRecording_05-27-2026_18-31-54_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7164662

[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/1746e4692736c0faac09998af6f2f0215f3cd153b24eb0e92d8572fbbfa5d2e1

[melvin-bot]

Triggered auto assignment to @grgia (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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

What is the root cause of that problem?

The emoji picker on iOS renders through PopoverWithMeasuredContent → Modal (BOTTOM_DOCKED) → BaseModal → ReanimatedModal → native RN <Modal>. On native, isSmallScreenWidth is hardcoded to true, so it always takes the BOTTOM_DOCKED Modal path.

This issue is most likely caused by a platform-level incompatibility with iOS 26 (beta) interacting with changes new to this staging release. The device is running iOS 26.5, which is a pre-release OS. The two most likely interaction points are:

1. The new ComponentDescriptorRegistry deadlock fix (PR #91736, merged May 27): This patch moves component descriptor construction outside the mutex lock in Fabric's ComponentDescriptorRegistry::add(). While this fixes a deadlock, it introduces a window where a descriptor is constructed but not yet registered in the maps. On iOS 26, if the threading model or CADisplayLink timing changed, a lookup for the Modal's component descriptor during this window could fail silently, preventing the modal from presenting.

2. KeyboardUtils.dismiss() promise hanging (src/utils/keyboard/index.ts:24-45): The showEmojiPicker flow calls KeyboardUtils.dismiss() which waits for keyboardDidHide. If iOS 26 changed keyboard event timing and the isVisible tracking variable is out of sync (stuck true when keyboard isn't actually visible), the promise would never resolve and setIsEmojiPickerVisible(true) would never be called.

No emoji picker, Modal, Popover, or keyboard code was changed between production (9.3.83-3) and staging (9.3.84-0) — the diff only contains web-specific changes (popstate guard) and unrelated features. This points to the new RN patch or dependency updates interacting with iOS 26's runtime.

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

First, confirm the root cause with targeted debugging on an iOS 26 device/simulator:

1. Add a console.log at EmojiPicker.tsx:123 inside the close() callback to verify whether setIsEmojiPickerVisible(true) is ever reached.
2. Add a console.log in KeyboardUtils.dismiss() to check whether isVisible is incorrectly true when the keyboard isn't shown.

If the keyboard promise is hanging: Add a timeout fallback to KeyboardUtils.dismiss() so it resolves after a reasonable delay (e.g., 500ms) even if keyboardDidHide never fires — preventing the entire emoji picker flow from being blocked.

If the Modal itself isn't rendering (keyboard promise resolves fine): The ComponentDescriptorRegistry patch (037) should be investigated by reverting it on a test build running iOS 26 to confirm whether it's the cause. If confirmed, the lock scope needs to be adjusted to protect lookups during the construction window.

What alternative solutions did you explore? (Optional)

• Checked whether ReanimatedModal's state machine (index.tsx:122-142) could get stuck with isTransitioning=true if scheduleOnRN from react-native-worklets doesn't fire on iOS 26 — possible but would affect all modals, not just the emoji picker.
• Checked whether the Activity component wrapping (EmojiPicker.tsx:268) could prevent initial mount — but this was added in PR decompose-composer 2: Activity for EmojiPicker and PopoverMenu #87394 (April 10) which is already in production.
• Checked FullStory babel plugin updates (2.3.2→2.4.0, 1.5.2→1.6.4) — unlikely to cause this specific issue without breaking many other components.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.