[Due for payment 2026-05-26] [Due for payment 2026-05-26] 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.75
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87852
Email or phone of affected tester (no customers): jsnodjosndjoisnjidoj@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. Open DM with any user.
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

Bug7155289_1778865670256.3.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @TaduJR

[melvin-bot]

@MonilBhavsar recently merged #87852, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

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

[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.

[melvin-bot]

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #87852 - "fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element" by @TaduJR (High confidence)
Related Issues: None

Recommendation: REVERT

PR #87852 introduced a NavigationFocusReturn system that captures the element that triggered forward navigation and restores focus to it on backward navigation. This causes the Merchant menu item to receive focus when navigating back from the Merchant step, so a subsequent Enter keypress activates that menu item again instead of creating the expense.

Assigned: @TaduJR (PR author), @MonilBhavsar (approving reviewer) from highest-confidence causing PR only
Labels: No label changes — DeployBlockerCash is correct for this frontend App bug. No DeployBlocker label was present to remove.

Detailed Analysis

Evidence

• The melvin-bot comment on the issue directly links PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 as the recently merged PR for investigation.
• PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 is included in the StagingDeployCash checklist (issue Deploy Checklist: New Expensify 2026-05-15 #90795) for version 9.3.75-0, which matches the reported version.
• The bug is reproducible on staging but NOT on production — consistent with a regression introduced by a newly staged PR.
• PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 introduced src/libs/NavigationFocusReturn.ts, a new focus management system that captures the triggering element on forward navigation and restores focus to it on backward navigation.

Verification

• The affected file is src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx, which renders a MenuItemWithTopDescription (a pressable/button element) that navigates to ROUTES.MONEY_REQUEST_STEP_MERCHANT when pressed.
• PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 modifies src/libs/NavigationFocusReturn.ts (new file, 504 additions) and src/hooks/useAutoFocusInput.ts — both are part of the focus arbitration system that is active on Web/Chrome.
• The Merchant step (src/pages/iou/request/step/IOURequestStepMerchant.tsx) uses useAutoFocusInput, which was also modified by PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 to integrate with the new ScreenFocusArbiter.

Root Cause

PR #87852 introduced NavigationFocusReturn.ts which listens to navigation state changes. When the user clicks the Merchant MenuItemWithTopDescription on the confirm page, the system records that element as the "trigger" for the forward navigation to the Merchant step. When the user types a merchant name and presses Enter (submitting the form), Navigation.goBack() is called, which is detected as a backward navigation. The NavigationFocusReturn system then restores DOM focus to the Merchant menu item on the confirm page.

With focus now on the Merchant menu item, the next Enter keypress activates it (the element is an interactive menu item rendered as a pressable/button), re-triggering Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_MERCHANT...) and opening the Merchant page again, instead of allowing the user to submit the expense via the confirm page's submit button.

This is a Web-only regression (only Windows: Chrome is checked in the issue) which is consistent with NavigationFocusReturn.ts being a .ts (not .native.ts) file — the native counterpart NavigationFocusReturn.native.ts added by the same PR is a stub with 15 lines that does nothing.