Reports - Blue highlight navigates separately from keyboard arrow selection

[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.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): sdjsdjosijnsodiosd@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. Go to workspace chat.
3. Click + > Create expense > Manual.
4. Enter amount > Next.
5. On confirm page, click Category.
6. Press Tab to navigate to Advertising.
7. Press arrow down key.
8. Scroll up the list.

Expected Result:

Blue highlight and keyboard selection will move together to the next category.

Actual Result:

Blue highlight navigates separately from keyboard arrow selection.
Advertising is highlighted with blue, Benefits is highlighted separately.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7107661_1773951648692.7.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: None

Recommendation: REVERT

PR #79834 is a large focus management overhaul (6985 additions, 148 deletions) that introduces a new NavigationFocusManager system and modifies focus behavior across the application. The PR added guards to prevent "focus stealing" in useSyncFocusImplementation (lines 33-38), which likely interferes with the normal focus synchronization needed for keyboard navigation in SelectionList components.

The bug is reproducible on staging but not production, confirming it was introduced in this release cycle. PR #79834 was merged in position #55 of the chronological deploy order.

Labels: DeployBlockerCash is correctly applied - no label changes needed (this is an App PR affecting frontend functionality).

Detailed Analysis

Evidence

1. Issue description: Blue highlight and keyboard arrow selection move separately when navigating categories using Tab + Arrow keys
2. PR fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 scope: Massive focus management changes affecting keyboard navigation
3. Timing: Reproducible on staging (v9.3.41-0) but not production - PR fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 is in this release
4. Melvin-bot assignment: Automatically assigned this issue to PR fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 author

Verification

PR #79834 modified core focus management infrastructure:

• Added NavigationFocusManager singleton for focus capture/restoration
• Modified useSyncFocusImplementation to add guard preventing focus on already-focused elements (lines 33-38)
• Modified FocusTrapForScreen with new focus restoration logic
• These changes affect ALL keyboard navigation throughout the app

The category selection flow uses:

• SelectionList component with useArrowKeyFocusManager hook for keyboard navigation
• useSyncFocus to sync visual highlight with actual DOM focus
• The new guard in useSyncFocusImplementation prevents syncing focus when activeElement is not body/documentElement/ref.current

Root Cause

The guard added in useSyncFocusImplementation (lines 33-38) prevents focus synchronization when an element is already focused. This breaks the critical sync between:

1. Visual highlight (managed by useArrowKeyFocusManager state)
2. Actual DOM focus (managed by useSyncFocus)

When navigating with arrow keys in a category list:

• useArrowKeyFocusManager updates the focusedIndex state (blue highlight)
• useSyncFocus should call .focus() on the newly highlighted element
• But the new guard blocks this because activeElement is not body
• Result: Blue highlight moves but DOM focus stays on previous element

This is a regression from the focus restoration feature - the guard is too aggressive and breaks existing keyboard navigation patterns.

[MelvinBot]

Proposal

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

After pressing Tab to navigate to a category item in a SelectionList (e.g., on the expense category picker), then pressing arrow down/up, the blue focus ring (:focus-visible box-shadow) stays stuck on the Tab-focused item while the background color highlight moves with the arrow keys. This causes two items to be visually highlighted simultaneously.

What is the root cause of that problem?

PR #79834 added a guard in useSyncFocusImplementation.ts (lines 33-37) to prevent useSyncFocus from stealing focus from elements restored by NavigationFocusManager during back-navigation:

const activeElement = document.activeElement;
if (activeElement && activeElement !== document.body && activeElement !== document.documentElement && activeElement !== ref.current) {
    return;
}

There are two independent highlighting systems in SelectionList:

1. React state highlighting (background color): Driven by focusedIndex in BaseSelectionList.tsx via useArrowKeyFocusManager. Arrow keys update this state, and BaseListItem.tsx applies getItemBackgroundColorStyle() to the focused item.

2. Native browser focus highlighting (blue box-shadow): Applied via the global CSS rule in web/index.html: :focus-visible { box-shadow: inset 0px 0px 0px 1px #5AB0FF; }. This follows whichever DOM element has native browser focus via .focus().

useSyncFocus is the bridge that keeps these two systems in sync - when focusedIndex changes, it calls .focus() on the new item's DOM element. But the new guard prevents this when another element already has focus.

The bug flow:

1. User presses Tab from the text input → focusedItemRef?.focus() is called (at BaseSelectionList.tsx:294), giving item A native browser focus (blue ring)
2. User presses Arrow Down → focusedIndex updates to item B, which gets the background color highlight
3. useSyncFocus fires for item B, but the guard sees item A as document.activeElement (not body, not the new ref) → returns early without calling .focus()
4. Result: Item A keeps the blue ring, item B has the background color → dual highlighting

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

Modify the guard in src/hooks/useSyncFocus/useSyncFocusImplementation.ts to allow .focus() calls when the currently focused element is a sibling list item within the same SelectionList. The guard should only protect against focus stealing from unrelated elements (i.e., elements restored by NavigationFocusManager).

One approach: check if the activeElement shares the same parent list container as ref.current. If they are siblings in the same list, allow the .focus() call to proceed. If activeElement is in a completely different component/context, keep the guard behavior.

An alternative simpler approach: use a flag or timestamp from NavigationFocusManager to track whether focus was recently restored (e.g., within the last animation frame), and only apply the guard during that window. Outside of that window, let useSyncFocus work normally.

What alternative solutions did you explore? (Optional)

1. Reverting the guard entirely — This would fix the SelectionList bug but re-break the focus restoration on back-navigation that PR fix: [Web] Focus restoration mechanism on back navigation (#76921) #79834 was designed to fix.

2. Adding .blur() on the old item before arrow key navigation — This would work around the guard by ensuring activeElement is document.body when useSyncFocus runs. However, this is fragile and could cause focus flash/flicker.

3. Making useSyncFocus aware of NavigationFocusManager directly — Import NavigationFocusManager in useSyncFocusImplementation.ts and check NavigationFocusManager.hasRecentlyRestoredFocus(). This is more coupled but very precise.

---

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 🙌

[cristipaval]

Asked for a retest here