[Due for payment 2026-05-26] [Due for payment 2026-05-26] [$250] Invoice - Pressing Enter on confirm page after selecting user returns to recipient list

[jponikarchuk]

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-7
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): sdsdjoijdoisnjodis@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:

Precondition:

• Enable Invoices in workspace settings.

1. Go to staging.new.expensify.com
2. Open FAB > Send invoice.
3. Enter amount > Next.
4. Enter email.
5. Use down arrow to select user and press Enter.
6. Press Enter on confirm page.

Expected Result:

Pressing Enter on confirm page after selecting user will send the invoice.

Actual Result:

Pressing Enter on confirm page after selecting user returns to recipient list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056471845688904959
• Upwork Job ID: 2056471845688904959
• Last Price Increase: 2026-05-18

Issue Owner

Current Issue Owner: @mkhutornyi

[melvin-bot]

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

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

[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 navigation state listener (handleStateChange) that tracks forward/backward navigation to restore keyboard focus. The listener misclassifies the form submission on the invoice confirm page as a backward navigation, scheduling a focus restore back to the recipient list. This causes the visible symptom where pressing Enter on the confirm page appears to "return" to the recipient list.

Assigned: @TaduJR (PR author), @mkhutornyi @MonilBhavsar (approving reviewers)
Labels: No label changes made. DeployBlockerCash is correct — this is an App PR causing a staging-only regression.

Detailed Analysis

Evidence

• The melvin-bot comment directly links the issue to PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 merged on 2026-05-14.
• PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 is in the current StagingDeployCash checklist (version 9.3.75-7).
• The issue is reproducible only on staging (not production), consistent with a regression introduced by this PR.
• The bug affects Web/Mac/Chrome — PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 explicitly targets web keyboard navigation (NavigationFocusReturn.ts is the web implementation, the .native.ts variant is a no-op stub).

Verification

• PR fix: Keyboard Navigation: Many Pages: The focus is lost and does not return to triggering element #87852 modifies src/libs/NavigationFocusReturn.ts, src/libs/Navigation/NavigationRoot.tsx, src/hooks/useAutoFocusInput.ts, and src/libs/ScreenFocusArbiter.ts.
• NavigationFocusReturn.ts introduces a handleStateChange function that listens to all navigation state changes and classifies them as forward/backward/lateral/noop.
• When the user presses Enter on the confirm page, the invoice is submitted and Navigation.goBack() is called. The state listener detects a route removal and classifies this as a "backward" navigation, which triggers scheduleRestore — attempting to focus the element that originally navigated forward to the confirm page (i.e., an element in the recipient list screen).
• The skipNextFocusRestore escape hatch exists in NavigationFocusReturn.ts but is only called from IOURequestStepMerchant.tsx — the invoice confirm page (IOURequestStepConfirmation.tsx) does not call it, so the restore is not skipped after form submission.

Root Cause

handleStateChange in NavigationFocusReturn.ts treats any backward navigation (route removal) as a case requiring focus restoration to the triggering element. However, when a form is submitted and navigation goes back as part of the submission success flow, restoring focus to the triggering element on the previous screen causes unexpected focus behavior that manifests as "returning to recipient list." The skipNextFocusRestore guard is not applied in the invoice confirm page's submission path, so the focus restore runs unconditionally after every goBack() call, whether it is user-initiated (Esc/Back) or form-submission-initiated (Enter to confirm).

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #87852 introduced useDialogContainerFocus which, after keyboard navigation (arrow keys set hadTabNavigation = true), auto-focuses the first interactive element inside the RHP dialog container. On the invoice confirm page, that first element is the back button in HeaderWithBackButton (which has role="button" and tabIndex=0).

With the back button focused, the confirm button's pressOnEnter keyboard shortcut is deactivated because shouldDisableEnterShortcut becomes true when activeElementRole is "button". So pressing Enter triggers the browser's native click on the focused back button, navigating back to the recipient list.

Data flow

1. User presses Down Arrow on participant list — hadTabNavigation becomes true
2. User presses Enter — recipient is selected, navigation proceeds to confirm page
3. Confirm page mounts inside RHP. Header.tsx calls useDialogContainerFocus
4. After transition, focusFirstInteractiveElement() queries FOCUSABLE_SELECTOR — first match is the back button
5. Back button receives focus with focusVisible: true
6. User presses Enter on confirm page
7. shouldDisableEnterShortcut = true (activeElementRole is "button") — confirm button's Enter shortcut is inactive
8. Native click fires on focused back button — onBackButtonPress → navigateBack() → returns to participants

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

The focusFirstInteractiveElement function in useDialogContainerFocus should skip navigation-related buttons (like the back button) when determining the initial focus target. Instead, it should focus the first content interactive element — for example, by excluding elements within the header's back button area, or by preferring elements with specific roles/attributes that indicate primary actions.

Alternatively, the confirm page could call skipNextFocusRestore() (which already exists but is only used in IOURequestStepMerchant) when navigating forward from the participants page, preventing the auto-focus from landing on the back button.

What alternative solutions did you explore?

• Making the back button's tabIndex=-1 would prevent it from receiving auto-focus, but would break keyboard accessibility for users who need to Tab to the back button.
• Having the confirm button's pressOnEnter ignore shouldDisableEnterShortcut when the focused element is a navigation button could work but would be a more fragile special case.

---

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.