[$250] List is not scrolled automatically during arrow key navigation on country select page

[m-natarajan]

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.78-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @rezkiy37
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Go to workspaces > any workspace > Company cards
2. Click Add cards button
3. Press Up/Down Arrow to select item

Expected Result:

List automatically scrolls down during navigation

Actual Result:

List is not scrolled automatically during arrow key navigation

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

bug.mov

Recording.2880.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057094276904549915
• Upwork Job ID: 2057094276904549915
• Last Price Increase: 2026-05-20

[MelvinBot]

Proposal

What is the root cause of that problem?

The SelectCountryStep explicitly passes shouldScrollToFocusedIndex={false} to SelectionList. This disables the auto-scroll behavior in BaseSelectionList — when the focused index changes via arrow keys, the onFocusedIndexChange callback early-returns without calling scrollToIndex.

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

Remove shouldScrollToFocusedIndex={false} from SelectCountryStep.tsx:138 (the default is true), so arrow key navigation scrolls the focused item into view.

What alternative solutions did you explore? (Optional)

Distinguishing between arrow-key-driven and search-driven focus changes inside BaseSelectionList to selectively enable scrolling. This is unnecessary because suppressNextFocusScrollRef already handles suppression for search-driven changes, so simply enabling shouldScrollToFocusedIndex should work correctly.

Investigation details

Data flow:

1. User presses ArrowDown/ArrowUp on the country selection page
2. useArrowKeyFocusManager updates the focusedIndex
3. onFocusedIndexChange fires — checks shouldScrollToFocusedIndex → it's false → returns early (BaseSelectionList.tsx:221-223)
4. scrollToIndex is never called → list doesn't scroll

Possibly related issue: #87758 — same shouldScrollToFocusedIndex={false} pattern in the personal cards country selection page.

---

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.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-20 13:43:40 UTC.

Proposal

What is the root cause of that problem?

SelectCountryStep tells the list to never scroll to the focused row. It passes shouldScrollToFocusedIndex={false} to SelectionList:

App/src/pages/workspace/companyCards/addNew/SelectCountryStep.tsx

Lines 137 to 139 in e8c6aa8

	shouldUpdateFocusedIndex
	shouldScrollToFocusedIndex={false}
	shouldScrollToFocusedIndexOnMount={false}

Inside BaseSelectionList, the arrow-key handler onFocusedIndexChange is what keeps the highlighted row in view. When shouldScrollToFocusedIndex is false, it returns early and scrollToIndex is never called, so pressing Up/Down moves the focus below the fold but the list stays put:

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 216 to 226 in e8c6aa8

	onFocusedIndexChange: (index: number) => {
	if (suppressNextFocusScrollRef.current) {
	suppressNextFocusScrollRef.current = false;
	return;
	}
	if (!shouldScrollToFocusedIndex) {
	return;
	}
	(shouldDebounceScrolling ? debouncedScrollToIndex : scrollToIndex)(index);
	},

This is a regression from PR #89584 ("Move pre-selected list items to top of list", merged 2026-05-05). Before it, the prop was absent and defaulted to true, so arrow navigation scrolled correctly — which is still the case on the sibling steps of this same flow (CardTypeStep, SelectBankStep, SelectFeedType) that don't set the prop.

The PR's real goal — pinning the saved country to the top — is achieved by moveInitialSelectionToTop plus shouldScrollToFocusedIndexOnMount={false} (which only controls initialScrollIndex on mount, keeping the header visible). shouldScrollToFocusedIndex={false} was an over-reach that additionally killed runtime arrow-key scrolling, which is the bug.

Note the same regression was applied by #89584 to two more production lists, so they have the identical broken behavior:

• App/src/pages/settings/Wallet/CountrySelectionList.tsx

  Lines 97 to 98 in e8c6aa8

  	shouldScrollToFocusedIndex={false}
  	shouldScrollToFocusedIndexOnMount={false}

• App/src/components/ValuePicker/ValueSelectionList.tsx

  Lines 34 to 35 in e8c6aa8

  	shouldScrollToFocusedIndex={false}
  	shouldScrollToFocusedIndexOnMount={false}

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

Drop shouldScrollToFocusedIndex={false} so it falls back to the default true, while keeping shouldScrollToFocusedIndexOnMount={false} (the two are independent — on-mount scroll vs. focus-driven scroll), so the saved country stays pinned at the top and the header stays visible, but arrow-key navigation scrolls the focused row into view again:

                 disableMaintainingScrollPosition
                 shouldSingleExecuteRowSelect
                 shouldUpdateFocusedIndex
-                shouldScrollToFocusedIndex={false}
                 shouldScrollToFocusedIndexOnMount={false}
                 addBottomSafeAreaPadding
                 shouldStopPropagation

This is safe on mount: onFocusedIndexChange only fires when focusedIndex actually changes (prevIsFocusedIndex === focusedIndex guard in useArrowKeyFocusManager), so restoring the default does not trigger a scroll on first render — only on real Up/Down presses.

Apply the same one-line removal to the two siblings that share this regression, src/pages/settings/Wallet/CountrySelectionList.tsx and src/components/ValuePicker/ValueSelectionList.tsx, so every list pinned by #89584 regains keyboard scrolling.

Finally, the three tests added by #89584 currently lock in the bug — they assert shouldScrollToFocusedIndex is false (the "disables focus-driven scroll" cases in tests/ui/SelectCountryStepTest.tsx, tests/ui/CountrySelectionListTest.tsx, tests/ui/ValueSelectionListTest.tsx). Those assertions and their descriptions should be updated to reflect the restored default while still asserting shouldScrollToFocusedIndexOnMount stays false and the pinned-to-top ordering is unchanged.

What alternative solutions did you explore? (Optional)

• Keeping shouldScrollToFocusedIndex={false} and instead calling scrollToIndex manually from a keyboard handler in SelectCountryStep — rejected: it reimplements logic BaseSelectionList already owns, and would have to be duplicated across the two other affected lists.
• Removing shouldScrollToFocusedIndexOnMount={false} as well — rejected: that would re-introduce a scroll to the pinned country on mount, hiding the "Where is your bank located?" header that Move pre-selected list items to top of list throughout the app #89584 deliberately keeps visible.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Eskalifer1 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022057094276904549915

[aswin-s]

Proposal

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

On the workspace Company cards → Add cards → country selection page (Web, desktop), pressing the Up/Down arrow keys moves the focus highlight through the country list but the list does not auto-scroll to keep the focused row in view. Expected: the list should scroll along with the focused row so the highlighted country is always visible during keyboard navigation.

What is the root cause of that problem?

In src/pages/workspace/companyCards/addNew/SelectCountryStep.tsx:138, the SelectionList is rendered with shouldScrollToFocusedIndex={false}. In BaseSelectionList.tsx:221, the arrow-key onFocusedIndexChange early-returns when that prop is false and never calls scrollToIndex, so focus advances but the list never scrolls. shouldScrollToFocusedIndexOnMount={false} on line 139 additionally suppresses any initial scroll to the pre-selected country.

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

1. In src/pages/workspace/companyCards/addNew/SelectCountryStep.tsx (lines 138–139), remove the shouldScrollToFocusedIndex={false} and shouldScrollToFocusedIndexOnMount={false} overrides so they fall back to the true defaults defined in BaseSelectionList.tsx:88-89. This restores both the on-mount scroll to the initially-selected country and the arrow-key follow-scroll behaviour.
2. Verify behaviour against sibling country/option pickers that already work correctly — CountrySelectorModal.tsx and PushRowModal.tsx (both touched by PR Move pre-selected list items to top of list throughout the app #89584) do not set shouldScrollToFocusedIndex={false}, so they rely on the default and scroll as expected. The fix aligns SelectCountryStep with that working pattern.
3. Manually retest the repro (Workspaces → any workspace → Company cards → Add cards) with arrow keys and confirm the list scrolls; also confirm the initially selected country (from getPlaidCountry) is scrolled into view on mount.

What alternative solutions did you explore? (Optional)

Keep shouldScrollToFocusedIndex={false} and add a manual scrollToIndex ref call in an onFocusedIndexChange-like callback — rejected because the prop already gates the built-in, correct behaviour; re-implementing it externally is strictly worse than removing the override.

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[MobileMage]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.