Web - Expense - Enter on confirm page returns to amount input page

[mitarachim]

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.54-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: #85221
Email or phone of affected tester (no customers): jsodinjosjdiosjndonjiso@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 FAB > Create expense > Manual.
3. Enter amount.
4. Press Enter.
5. On confirm page, press Enter.

Expected Result:

App will proceed to create the expense or throw error if merchant is not entered.

Actual Result:

Enter on confirm page returns to amount input page, due to the blue box focus on the RHP back button.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7124256_1775607795681.3.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @TaduJR

[melvin-bot]

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

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

PR #85221 introduced useDialogContainerFocus to improve screen reader announcements. After each screen transition within the RHP dialog, this hook queries the dialog container for the first focusable element and calls .focus() on it (src/hooks/useDialogContainerFocus/index.ts:5-28).

On the expense confirm page, no input field claims focus automatically, so document.activeElement remains document.body when the hook fires. The first interactive element in DOM order is the back button in HeaderWithBackButton (src/components/HeaderWithBackButton/index.tsx:244-269), which matches the FOCUSABLE_SELECTOR (button, [role="button"], ...). The back button silently receives focus. When the user presses Enter expecting to submit the expense, Enter activates the focused back button instead, navigating back to the amount page.

The focus chain: pushLabel() resets initialFocusClaimedRef → claimInitialFocus() returns true → useDialogContainerFocus runs → back button is first match → .focus() called → Enter activates it.

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

The useDialogContainerFocus hook in src/hooks/useDialogContainerFocus/index.ts should skip the back button when selecting the first focusable element. The simplest approach: exclude elements whose aria-label is the "Back" label (or that match the back button's nativeID) from the candidate list, so focus falls to the next meaningful interactive element on the page instead.

Alternatively, HeaderWithBackButton could set tabIndex={-1} on the back button's PressableWithoutFeedback so it's excluded from the FOCUSABLE_SELECTOR query — but this would also remove it from normal tab order, which may hurt keyboard accessibility. A targeted exclusion in the hook is safer.

What alternative solutions did you explore? (Optional)

• Adding tabIndex={-1} to the back button: Would fix the auto-focus issue but removes the back button from tab order entirely, degrading keyboard navigation.
• Having the confirm page explicitly focus its submit button on mount: Would work for this specific page but doesn't prevent the same problem on other RHP screens that lack an auto-focused element.
• Reverting PR fix: Screen Reader: Many Pages: There is no dialog role and title announced #85221: Would fix the regression but lose the screen reader improvements.

---

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.