Company Cards - Selected country doesn´t remain highlighted after being selected.

[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.55-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: #85447
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Other

Action Performed:

Prerequisite: Account has at least one workspace with "Company Cards" enabled.

1. Open the Expensify app.
2. Navigate to "Workspaces" and open any workspaces.
3. Tap on "Company Cards" > "Add Cards"
4. Type any country name on search input. (For example: Switzerland)
5. Note that the country is displayed highlighted before being selected.
6. Select the country.
7. Note that a checkmark appears, but country is not highlighted anymore.
8. Delete a few letters on search input.
9. Note that while deleting, country is highlighted again.

Expected Result:

After searching for a country on "Country List" and selecting it, it should remain highlighted.

Actual Result:

Searched country doesn´t remain highlighted after being selected on "Country 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

[melvin-bot]

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

[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: #85447 - "fix: stabilize reopen ordering in basic pickers" by @marufsharifi (High confidence)
Related Issues: #69184 (the original issue this PR was fixing)

Recommendation: REVERT

PR #85447 introduced a regression in country selection highlighting. The fix intended to stabilize the selected item at the top of the list and prevent scroll jumps, but introduced a bug where the highlight (focus) is lost after selecting a country and then modifying the search input.

Assigned: @marufsharifi (PR author), @linhvovan29546 (approving reviewer), @srikarparsi (approving reviewer)
Labels: DeployBlockerCash retained (frontend App PR caused the regression, staging-only)

Detailed Analysis

Evidence

• The issue is staging-only (version 9.3.55-0, not reproducible in production), pointing to a recently merged staging PR.
• The melvin-bot and the issue body both link directly to PR fix: stabilize reopen ordering in basic pickers #85447 as the causing PR.
• PR fix: stabilize reopen ordering in basic pickers #85447 was merged on 2026-04-08 and is item Fix deploy action #39 in the StagingDeployCash chronological list, placing it squarely in the current release window.
• The PR title explicitly names the affected flows: "stabilize reopen ordering in basic pickers" — and the bug is in the country picker selection highlighting behavior.

Verification

Affected files confirmed modified by PR #85447:

• src/pages/workspace/companyCards/addNew/SelectCountryStep.tsx — the exact screen described in the bug steps
• src/components/CountryPicker/CountrySelectorModal.tsx
• src/hooks/useInitialSelection.ts (new file introduced by PR)
• src/libs/SelectionListOrderUtils.ts (new file introduced by PR)
• src/components/SelectionList/BaseSelectionList.tsx

Root Cause

The PR introduced useInitialSelection, a hook that deliberately snapshots the selected value at open/focus time and does NOT update it when the user makes a new selection mid-session. It resets only when resetDeps changes (e.g., isVisible toggles) or the screen regains focus.

This snapshot (initialSelectedValue) is used as initiallyFocusedItemKey passed to SelectionList. The focused/highlighted row in BaseSelectionList is driven by useSelectedItemFocusSync, which finds the item matching initiallyFocusedItemKey via isItemSelected. Because initialSelectedValue is frozen at the original pre-selection value and does not update after the user taps a new country, the focusedIndex calculation does not follow the new selection.

The bug manifests as:

1. User searches and selects Switzerland — currentCountry updates to CH, but initialSelectedValue stays at whatever was originally frozen (or undefined).
2. initiallyFocusedItemKey still points to the old value, so useSelectedItemFocusSync does not move focus to the newly selected item.
3. When the user deletes search characters, useSearchFocusSync detects a search-clear event, calls data.findIndex(isItemSelected) (checking item.isSelected), finds the correct item, and restores focus — which is why the highlight reappears while deleting.
4. The result: highlight disappears immediately after selection while a search term is active, and only re-appears when the search is cleared.

[MelvinBot]

Proposal

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

After searching for a country in the Company Cards → Add Cards → Select Country flow and selecting it, the selected country loses its highlight. It reappears only when the user modifies the search input.

What is the root cause of that problem?

The background highlight in BaseListItem.tsx:205-207 is gated behind isFocused:

isFocused && shouldHighlightSelectedItem && StyleUtils.getItemBackgroundColorStyle(...)

When a user selects an item during an active search, two hooks conspire to remove focus:

1. useSearchFocusSync.ts:84-89 — detects selectedOptionsChanged with the same data.length and resets focusedIndex to -1.
2. useSelectedItemFocusSync.ts:38-41 — could restore focus to the selected item, but explicitly bails out when searchValue is truthy.

Result: the item has isSelected: true but isFocused: false, so the background style short-circuits and no highlight is rendered.

When the user deletes a letter from the search, useSearchFocusSync detects a search change and resets focusedIndex to 0, which may land on the selected item, restoring the highlight — matching the behavior described in the issue.

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

In useSelectedItemFocusSync.ts:38, remove the searchValue bail-out so that focus syncs to the selected item even during active search. The guard should become:

if (selectedItemIndex === -1 || selectedItemIndex === focusedIndex) {
    return;
}

This ensures that when an item is selected while searching, focusedIndex is updated to point to it, and the highlight renders correctly.

Data flow trace

1. User types "Swi" → debouncedSearchValue = "Swi", countries filtered
2. User taps "Switzerland" → setSelectedCountry('CH') → currentCountry = 'CH'
3. searchResults recomputed: Switzerland gets isSelected: true
4. useSearchFocusSync sees selectedOptionsCount changed (0→1), same search, same data.length → setFocusedIndex(-1)
5. useSelectedItemFocusSync sees searchValue is truthy → skips syncing focus
6. BaseListItem: isFocused(false) short-circuits the background style → no highlight
7. User deletes a letter → search changes → useSearchFocusSync resets to index 0 → highlight may reappear

What alternative solutions did you explore? (Optional)

• Removing the isFocused gate from the isSelected background style in BaseListItem — this would fix the symptom but could have unintended visual side effects across all selection lists.
• Making useSearchFocusSync not reset focus when selectedOptionsChanged during active search — riskier since that reset serves other purposes (e.g., keeping focus sane when options reorder).

The useSelectedItemFocusSync fix is the most targeted: it only affects the case where a user actively selects an item, which should always result in that item gaining focus.

---

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.