IOU - Pressing Enter after pressing Enter on Merchant opens Merchant instead of creating expense

[lanitochka17]

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.41-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: #79834
Email or phone of affected tester (no customers): sijnisojnsiojdosjjo2@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Create expense > Manual.
4. Enter amount > Next.
5. On confirm page, click Merchant.
6. Enter merchant and press ENTER.
7. Press ENTER again.

Expected Result:

Expense will be created (similar to production).

Actual Result:

Merchant page opens.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7107655_1773951317736.4.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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 the expense confirmation page, after editing the Merchant field and pressing Enter to save, pressing Enter again opens the Merchant page instead of creating the expense. This works correctly in production but is broken in staging after PR #79834 was merged.

What is the root cause of that problem?

PR #79834 introduced a focus restoration mechanism for back navigation. When the user clicks the Merchant MenuItem to edit it, NavigationFocusManager captures that element for the confirmation route. When navigating back from the Merchant page, FocusTrapForScreen restores focus to the Merchant MenuItem after a ~300ms delay (delayInitialFocus: CONST.ANIMATED_TRANSITION).

This causes two compounding problems:

1. The confirm button's Enter shortcut gets deactivated. ButtonWithDropdownMenu uses pressOnEnter which registers a global Enter keyboard shortcut. However, Button's KeyboardShortcutComponent (src/components/Button/index.tsx:194-232) has a shouldDisableEnterShortcut check that disables the shortcut when any element with an accessibility role (other than presentation) has focus. Since the Merchant MenuItem has role='button', the confirm button's Enter shortcut is disabled.

2. The browser activates the focused MenuItem instead. When Enter is pressed on a focused role='button' element, the browser fires a native synthetic click event. React Native Web's PressResponder translates this to onPress, which navigates to the Merchant page again.

The key code path:

• NavigationFocusManager captures the Merchant MenuItem on pointerdown/keydown (capture phase) at src/libs/NavigationFocusManager/index.web.ts
• FocusTrapForScreen restores it via initialFocus callback at src/components/FocusTrap/FocusTrapForScreen/index.web.tsx:175-198
• blurActiveInputElement only blurs INPUT/TEXTAREA elements, not role='button' elements, so the restored focus persists at src/libs/Accessibility/blurActiveInputElement/index.ts:5-17

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

The fix should prevent focus restoration from restoring focus to the element that triggered the navigation away from the screen. When the user clicks the Merchant MenuItem to navigate to the Merchant edit page, restoring focus to that same MenuItem on back-navigation is counterproductive — the user has already completed that interaction.

In FocusTrapForScreen's initialFocus callback, add a check: if the captured element is a non-input interactive element (e.g., role='button' MenuItem) that triggered the navigation, return false instead of restoring focus to it. This allows the confirm button's Enter shortcut to remain active, and pressing Enter will submit the expense as expected.

Alternatively, in NavigationFocusManager, skip capturing the element when the interaction (click/Enter) triggers navigation (i.e., when the element's press handler navigates to a new screen). This could be done by clearing the capture in a microtask if navigation occurred.

What alternative solutions did you explore? (Optional)

1. Modifying shouldDisableEnterShortcut in Button to not disable when the focused element is a MenuItem on the confirmation page — too specific, doesn't fix the general problem.
2. Setting tabIndex={-1} on MenuItems in the confirmation list — would break keyboard accessibility for those fields.
3. Adding an onKeyDown handler to MenuItem that prevents Enter activation after focus restoration — fragile timing-based solution.

---

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