[$250] TC-3707 - Arrows not working on emoji reaction menu

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.43-0-staging
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/test-runs/66856245/folder/13176723/41237060/1615054868
Email or phone of affected tester (no customers): applaisetester+ma1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: CHrome Windows 11
App Component: Chat Report View

Action Performed:

1. Click over a message and use the tab key to reach the emoji reaction button
2. Verify that the emoji picker is correctly positioned under the message.
3. Using the arrow keys, select any emoji with Enter

Expected Result:

Select the emoji using keyboard arrows

Actual Result:

keyboard arrows not selecting emojis after tab is pressed, only tab and shift+tab works

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bandicam.2026-07-30.12-09-54-769.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082757399178743317
• Upwork Job ID: 2082757399178743317
• Last Price Increase: 2026-08-12

[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/4a44344ce3c8d5448a10532b75d2bcf66eb8fe4ae2a38a87272ab413a76028d8

[MelvinBot]

Proposal

⚠️ Medium confidence — the mechanism is clear from the code, but the exact competing handler needs one runtime check to pin down (see the note at the end).

What is the root cause of that problem?

Emoji-picker arrow navigation is not driven by DOM focus — it's driven by App's global, document-level keyboard-shortcut dispatcher. The picker registers ARROW_UP/DOWN/LEFT/RIGHT via useArrowKeyFocusManager → useKeyboardShortcut, which pushes onto a priority stack where only the top handler for a key runs and the event does not bubble to lower subscribers (bindHandlerToKeydownEvent/index.ts:33-66 — .every() stops after the first non-bubbling handler).

When you open the picker by tabbing to a message's reaction button, the reaction lives inside a report-action context menu that is deliberately kept mounted: the open path calls openContextMenu() → setShouldKeepOpen(true) (ContextMenuActions.tsx:456-472). That keeps the context menu's own arrow-key subscriber active — shouldEnableArrowNavigation = !isMini && (isVisible || shouldKeepOpen) (BaseReportActionContextMenu.tsx:288) — sitting on the arrow stack alongside the picker's handler. Arrow keys are consumed by the top subscriber and never reach the picker, so focusedIndex never changes and no emoji highlights. Tab/Shift+Tab keep working because those go through the picker's independent DOM focus trap (FocusTrapForModal), not the shortcut stack — which is exactly the reported symptom (tab works, arrows don't).

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

Ensure the context-menu arrow-key subscriber is not active while the emoji picker is open on the tab-to-reaction path, so the picker's handler is the top-of-stack subscriber for the arrow keys. Options:

• Suppress the kept-open context menu's arrow navigation while an emoji picker is showing (gate shouldEnableArrowNavigation on the picker not being open), or
• Have the picker register its arrow handlers at a higher priority so they land on top of the stack while it is open.

Either way the picker's useArrowKeyFocusManager (EmojiPickerMenu/index.tsx:161-173) must be the receiver of arrow keydowns whenever the picker is visible.

Investigation details & what to verify at runtime

• Arrow handlers gate only on isFocused/allowHorizontalArrowKeys (useArrowKeyFocusManager.ts:113-114,193-194); up/down are effectively ungated here, so the picker's own config does not explain up/down also dying — pointing at stack ordering rather than the picker's gating.
• The composer being focused is ruled out: the picker excludes only TEXTAREA with captureOnInputs: true, but the composer is a contentEditable DIV and the search box an INPUT, so neither would block the picker's handler.
• Runtime check to confirm the exact culprit: reproduce the tab-to-reaction flow on Windows Chrome, and when arrows fail inspect eventHandlers['ARROWDOWN'] in src/libs/KeyboardShortcut/index.ts — confirm a BaseReportActionContextMenu handler sits above the picker's — and confirm shouldEnableArrowNavigation/shouldKeepOpen are true while the picker is open.

What alternative solutions did you explore? (Optional)

Rather than reordering the stack, allow the arrow event to bubble past the context-menu handler when the picker is open (return shouldBubble from the context menu's arrow handler in that state).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97442) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@FitseTLT Huh... This is 4 days overdue. Who can take care of this?

[FitseTLT]

reviewing

[FitseTLT]

🆘 C+ Help Wanted