Spend - Pre-selected items are not moved to the top

[applause-bot]

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.4.22-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94609
Email or phone of affected tester (no customers): gocemate+b21549066112@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 10/Chrome
App Component: Search

Action Performed:

1. Go to Reports (Spend) → Filters pill → From
2. Select few users and verify they don't move to the top
3. Go to other filter option
4. Navigate back to From filter

Expected Result:

Pre-selected items not moved to the top

Actual Result:

Pre-selected items are not moved to the top

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7194291_1782739737443.Recording__959.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7194291

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/96ee8b57ecbd77bb17fc2ead3fe37ad6c074bc02e02616d5fa2d88a32c7bfe62

[melvin-bot]

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

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

[mkhutornyi]

@jponikarchuk this is expected when number of rows are less than 12.
Pre-selected items are moved to the top only for large list (>= 12)

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a regression from PR #94609 (the PR this deploy blocker is assigned to).

Before that PR, UserSelector (the From / To / Attendee / Assignee picker) unconditionally prefixed the currently‑selected rows to the top of the list:

return [...availableOptions.selectedOptions, ...availableOptions.personalDetails];

PR #94609 replaced that with a snapshot‑based reorder using the shared moveInitialSelectionToTop util, called from UserSelector.tsx:63-66. That util bails out and returns the list unreordered when the list has fewer than 12 items:

if (initialSelectedValues.length === 0 || items.length < CONST.STANDARD_LIST_ITEM_LIMIT) {
    return items; // STANDARD_LIST_ITEM_LIMIT = 12
}

So when the From list has fewer than 12 selectable people (the QA test account does), pre‑selected items are never floated to the top — even though production (old code) always floated them. That's exactly the "not reproducible in production" signal.

The reopen‑remount path itself works correctly: switching filters in the popover remounts UserSelector (key={filterKey}), and the selection is synced live from the URL back into the Onyx form (useSearchFilterSync), so value is fresh on remount. The only thing suppressing the reorder is the < 12 size guard. For lists with 12+ people the reorder works as intended — which is why the PR author's testing of step 7 passed.

Why the threshold exists & evidence chain

• PR Fix scroll/reorder jump when selecting in From/To/Attendee/Assignee search filters #94609 intentionally switched the threshold to STANDARD_LIST_ITEM_LIMIT (12) — "the same point at which the search input appears. Short, fully-visible lists are left in their natural order." That decision is the regression: the old UserSelector reordered regardless of length.
• Selection → URL (Navigation.setParams({q}) in useUpdateFilterQuery.tsx) → re-parsed into SEARCH_ADVANCED_FILTERS_FORM via useSearchFilterSync → read back as value in the popover. Confirmed fresh on remount, so list size is the sole determinant.
• moveInitialSelectionToTop is shared with CountrySelectionList, ValueSelectionList, and PushRowModal, so the guard can't simply be removed globally without changing their behavior.

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

Restore the prior "always float selected to top" behavior for the people pickers specifically, without changing the other consumers of the shared util:

• Add an optional flag to moveInitialSelectionToTop (e.g. ignoreListSizeThreshold/minListSize) that skips the items.length < STANDARD_LIST_ITEM_LIMIT short‑circuit, and pass it from UserSelector.tsx:63. The other callers (Country/Value/PushRow) keep the existing threshold.
• This makes pre‑selected items float to the top in the From/To/Attendee/Assignee filters for short lists too, matching production behavior, while keeping the no‑scroll/no‑jump fix from Fix scroll/reorder jump when selecting in From/To/Attendee/Assignee search filters #94609 intact.

Because this is an assigned deploy blocker, the fastest safe option is to revert PR #94609 and re‑land with the threshold fix; otherwise the targeted change above is small and low‑risk.

What alternative solutions did you explore? (Optional)

Lowering/removing the threshold in the shared util globally — rejected because it would also reorder short Country/Value/PushRow lists, changing unrelated behavior.

Related: Expensify/App#69184 (move pre-selected items to top across the app) and Expensify/App#61414 (the issue PR #94609 fixed) are the relevant context.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94843) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[mkhutornyi]

This is expected. We can close this.