Web - Expense - To field is highlighted after returning to confirm page

[vincdargento]

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): sodjnsojosidjosij@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 > Next.
4. On confirm page, click To field.
5. Click RHP back button.

Expected Result:

To field will not be highlighted after returning to confirm page.

Actual Result:

To field is highlighted after returning to confirm page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

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

[ikevin127]

♻️ Similar to #85866, find breakdown comment here as we need a decision on approaching this type of issue.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After creating a manual expense (FAB > Create expense > Manual > Enter amount > Next), clicking the "To" field on the confirm page opens the participants RHP. When pressing the RHP back button to return to the confirm page, the "To" field remains visually highlighted. It should not be highlighted.

What is the root cause of that problem?

PR #79834 introduced a focus restoration mechanism for back navigation on web. Here's the chain of events causing the bug:

1. Capture on click: When the user clicks the "To" row, NavigationFocusManager captures the pressed PressableWithFeedback element during the pointerdown capture phase (index.web.ts:340-407), storing a reference keyed by route.

2. Restore on back: When the user navigates back from the participants RHP, FocusTrapForScreen's initialFocus callback retrieves the stored element and focuses it (FocusTrapForScreen/index.web.tsx:175-198).

3. Focus triggers highlight: The onFocus handler in ListItemRenderer (ListItemRenderer.tsx:92-101) fires and calls setFocusedIndex, which causes BaseListItem to apply a highlight background via getItemBackgroundColorStyle (BaseListItem.tsx:140-142).

4. Blur doesn't clear it: The useFocusEffect in MoneyRequestConfirmationList calls blurActiveInputElement() (MoneyRequestConfirmationList.tsx:1150-1163), but this function only blurs INPUT and TEXTAREA elements (blurActiveInputElement/index.ts:5-17). Since the "To" row is a PressableWithFeedback (button), it is not blurred, and the highlight persists.

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

In MoneyRequestConfirmationList.tsx at line 1158, change blurActiveInputElement() to blurActiveElement() (imported from src/libs/Accessibility/blurActiveElement).

The useFocusEffect fires after the animation transition delay and InteractionManager.runAfterInteractions, which means it executes after the FocusTrap's focus restoration. Using blurActiveElement() will blur the restored focus on the "To" row pressable, removing the unwanted visual highlight.

The comment on line 1157 ("Don't blur other elements to preserve focus restoration on back navigation") was added in the same PR that introduced this bug. The MoneyRequestConfirmationList doesn't need to preserve restored focus on list items since they are navigation triggers (not form inputs that benefit from persistent focus).

What alternative solutions did you explore? (Optional)

1. Gate ListItemRenderer.onFocus on keyboard interaction: Only call setFocusedIndex when the focus event comes from a real keyboard interaction rather than programmatic FocusTrap restoration. This is cleaner in theory but harder to detect reliably across browsers (sourceCapabilities is Chrome-only).

2. Skip focus capture for SelectionList items in NavigationFocusManager: Don't let handleInteraction capture elements inside a SelectionList. However, this removes focus restoration entirely for those elements, which may hurt accessibility for keyboard/screen reader users.

3. Reset focusedIndex externally when screen regains focus: Have MoneyRequestConfirmationList reset the SelectionList's internal focusedIndex to -1 on focus. This would require exposing internal state, adding unnecessary complexity.

---

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.

[ikevin127]

I wouldn't block deploy on this as it's just a UI/UX regression that we can tackle in a follow-up 🙌

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.