Reports - Blue highlight appears on divider between LHN & central pane after closing report with ESC

[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): sdjsoidjnosjdiodsnj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a new report.
4. Go to Reports > Reports.
5. Click on the empty report in central pane.
6. Open the report.
7. Press ESC key.

Expected Result:

No blue highlight will appear.

Actual Result:

Blue highlight appears on the divider line between LHN and central pane.
If Step 5 is not performed, blue highlight will appear on report row then it jumps to Reports tab.

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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #79834 - "fix: [Web] Focus restoration mechanism on back navigation (#76921)" by @mavrickdeveloper (High confidence)
Related Issues: #76921 (original issue this PR fixed)

Recommendation: REVERT

PR #79834 introduced a comprehensive focus restoration mechanism that captures and restores keyboard focus during navigation. However, it has an unintended side effect where pressing ESC to close a report causes a blue highlight to appear on the divider between LHN and central pane. This indicates the focus restoration logic is incorrectly focusing on a non-interactive element that should not receive visible focus.

Labels: Keeping DeployBlockerCash label (no changes needed - this is a frontend bug affecting App deploy)

Detailed Analysis:

Evidence:
PR #79834 was merged on 2026-03-19 at 11:44:25Z and is included in the v9.3.41-0 staging deploy. The issue is:

• Reproducible on staging (where fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 is deployed)
• NOT reproducible on production (where fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 is not yet deployed)
• Directly related to the focus restoration mechanism introduced in this PR

The PR introduced NavigationFocusManager which handles:

• Capturing focused elements before navigation
• Restoring focus when returning to screens
• ESC key tracking for back navigation

Verification:
Files modified by PR #79834 that are relevant to this bug:

• src/libs/NavigationFocusManager/index.web.ts (new file, 825 lines) - core focus restoration logic
• src/components/FocusTrap/FocusTrapForScreen/index.web.tsx - integrates NavigationFocusManager with screen lifecycle
• src/libs/focusUtils/index.web.ts - utilities to determine if elements are focusable

The reproduction steps specifically involve:

1. Opening a report
2. Pressing ESC to close it
3. Blue highlight appears on the divider (visual focus indicator)

Root Cause:
The NavigationFocusManager captures the active element before navigation and attempts to restore it when navigating back via ESC. The bug is that when closing a report with ESC, the focus restoration logic is incorrectly identifying and focusing on the divider element between LHN and central pane.

The divider should not be focusable/interactive, but the focus restoration mechanism is either:

1. Capturing it as the "last focused element" incorrectly, OR
2. Failing to find the correct element to restore focus to, and falling back to an incorrect element

This is a regression from the PR goal of improving accessibility - while it successfully restores focus in many scenarios, it introduces a new visual bug where focus lands on inappropriate elements.