Pin initially-selected items to the top of long BankAccount and Card filter lists

[MelvinBot]

Explanation of Change

BankAccountSelector / CardSelector filters render their rows through SelectionListWithSections and group selected rows into a pinned top section.
Previously that section was keyed on the live isSelected flag, so toggling a row's selection while the filter was open made it immediately jump between the "selected" and "unselected" sections.

This snapshots the values that were selected when the filter first opened (via useInitialValue) and keys section membership on that snapshot instead of the live selection, while each row's checkbox still reflects the current selection.
So the initially-selected accounts/cards stay floated at the top on first render, and selecting/deselecting a row no longer makes it jump between sections.

The pinning is gated on list length: pre-selected items are only floated to the top when the list has at least CONST.STANDARD_LIST_ITEM_LIMIT (12) items.
For shorter lists the items stay in their natural order and nothing is pinned. Applies this < 12 gate to these two section-grouping selectors.

Fixed Issues

$ #61414

Tests

Long list (pinning applies — 12 or more items):

1. Sign in with an account that has 12 or more connected bank accounts (and, for the Card filter, 12 or more cards), so the list reaches the STANDARD_LIST_ITEM_LIMIT (12) that enables pinning.
2. Navigate to Search (Spend).
3. Open Filters > Bank account (then repeat the steps for Card).
4. Select one or more items, switch to another filter, then return to this filter.
5. Verify the previously-selected items are floated to the top section on first render.
6. While the filter is open, toggle an item's selection and verify it does not jump between sections — its checkbox updates in place.
7. Type in the search box and verify a pinned item that still matches stays at the top.

Short list (pinning does NOT apply — fewer than 12 items):
8. Repeat with an account that has fewer than 12 bank accounts / cards.
9. Select one or more items, switch to another filter, then return.
10. Verify the selected items are not pinned to the top — every item stays in its natural order and the selected ones are simply marked in place.

• Verify that no errors appear in the JS console

Offline tests

Same as Tests

QA Steps

Same as Tests

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I verified that similar component doesn't exist in the codebase
• I verified that all props are defined accurately and each prop has a /** comment above it */
• I verified that each file is named correctly
• I verified that each component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
• I verified that the only data being stored in component state is data necessary for rendering and nothing else
• In component if we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
• For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
• I verified that component internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
• I verified that all JSX used for rendering exists in the render method
• I verified that each component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
...ts/Search/FilterComponents/BankAccountSelector.tsx	87.27% <100.00%> (+87.27%)	⬆️
...omponents/Search/FilterComponents/CardSelector.tsx	91.22% <100.00%> (+91.22%)	⬆️
... and 18 files with indirect coverage changes

[MelvinBot]

Both failing checks are unrelated to this PR — no code fix is needed.

build (Expensify Dev, Debug, true) (Remote Build iOS) — fails at CocoaPods install with a MapboxMaps version conflict:

[!] CocoaPods could not find compatible versions for pod "MapboxMaps":
  In snapshot (Podfile.lock):  MapboxMaps (= 11.23.1, ~> 11.23.1)
  In Podfile:  rnmapbox-maps ... depends on  MapboxMaps (~> 10.19.0)

This PR only touches BankAccountSelector.tsx and CardSelector.tsx — it changes no native dependency, package.json, or Podfile.lock. The same build is already failing on main (run 29317114862 with the identical MapboxMaps error), and there's an in-flight branch (jasperhuangg/upgrade-mapbox-10.3.2) fixing the Mapbox version mismatch. It'll clear once that lands and this branch is updated from main.

checklist (PR Author Checklist) — expected. This is the standard author checklist gate; it needs the human co-author to fill in the Tests/QA sections and tick the boxes. It's not something I fix.

Everything under this PR's control is green — typecheck, ESLint, Oxfmt, unit tests, Storybook, and the Android/dev builds all passed.

Evidence

• PR diff touches only the two selector .tsx files (no Podfile.lock / package.json / native changes).
• main's "Remote Build iOS" run 29317114862 fails with the same CocoaPods could not find compatible versions for pod "MapboxMaps" error.
• jasperhuangg/upgrade-mapbox-10.3.2 runs of the same workflow are passing, indicating the fix is in progress.

[MelvinBot]

Re-checked — the situation is unchanged, and there's still nothing in this PR to fix or push.

• build (Expensify Dev, Debug, true) (Remote Build iOS) — still failing on the same MapboxMaps CocoaPods conflict, and main itself is still red on this exact build (latest completed run ac6069a66 fails identically). The Mapbox version fix hasn't merged to main yet, so there's nothing to pull in — this'll clear on its own once that lands and this branch is updated from main.
• checklist (PR Author Checklist) — expected; needs the human co-author to fill in Tests/QA and tick the boxes. Not something I can fix.

Everything under this PR's control (typecheck, ESLint, Oxfmt, unit tests, Storybook, Android/dev builds) is green. See my earlier comment for the full breakdown.

[MelvinBot]

Update — the checks re-ran and there's now a second failure, but all three failing checks are unrelated to this PR, which touches only BankAccountSelector.tsx and CardSelector.tsx. Nothing here needs a code fix; the two real failures are both broken on main.

1. test (job 5) → ExportOnyxStateTest.ts (NEW) — the "every ONYXKEYS value must be in one of the four buckets" test fails because the Onyx key nvp_dismissedTrialPaymentReminder is defined in src/ONYXKEYS.ts:303 but is not assigned to any export bucket in src/libs/ExportOnyxState/common.ts. That key was added to main by #84049 without being bucketed, so the test is red on main itself and for every open PR — not something this PR introduced. The owner of that key needs to add it to one of ONYX_KEY_EXPORT_RULES / onyxKeysToRemove / safeOnyxKeys / onyxKeysToMaskFragileData.

2. build (Expensify Dev, Debug, true) (Remote Build iOS) — same unrelated MapboxMaps CocoaPods version conflict as before (Podfile.lock pins 11.23.1, @rnmapbox/maps requires ~> 10.19.0). Also failing on main; the in-flight jasperhuangg/upgrade-mapbox-10.3.2 branch fixes it.

3. checklist (PR Author Checklist) — expected; needs the human co-author to fill in Tests/QA and tick the boxes.

This PR's own code is green: typecheck, ESLint, Oxfmt, Storybook, and the Android/dev builds all pass. Once #84049's key is bucketed and the Mapbox fix lands on main, merge main into this branch and the checks will clear.

Evidence

• PR diff touches only the two selector .tsx files — no ONYXKEYS.ts, common.ts, Podfile.lock, or package.json changes.
• On main (bfcfc48): nvp_dismissedTrialPaymentReminder is present in ONYXKEYS.ts but absent from all four buckets in common.ts, so ExportOnyxStateTest.ts:317 fails there too.
• main's "Remote Build iOS" run 29317114862 fails with the identical MapboxMaps CocoaPods error.

[MelvinBot]

Re-checked — status is unchanged from my previous comment, and there is still nothing in this PR to fix or push. This PR touches only BankAccountSelector.tsx and CardSelector.tsx, and all three failing checks are inherited from main:

• test (job 5) — ExportOnyxStateTest.ts fails because nvp_dismissedTrialPaymentReminder (src/ONYXKEYS.ts:303) is defined but not assigned to any export bucket in src/libs/ExportOnyxState/common.ts. I verified on main: the key is present in ONYXKEYS.ts and absent from common.ts there, so this test is red on main and every open PR. The owner of that key must bucket it.
• build (Expensify Dev, Debug, true) (Remote Build iOS) — CocoaPods MapboxMaps version conflict (Podfile.lock pins 11.23.1, @rnmapbox/maps requires ~> 10.19.0). Also red on main; being fixed by the in-flight jasperhuangg/upgrade-mapbox-10.3.2 branch.
• checklist (PR Author Checklist) — expected; the human co-author fills in Tests/QA and ticks the boxes.

I can't resolve these by pushing to this branch — they clear once (1) the ONYX key owner buckets nvp_dismissedTrialPaymentReminder on main, and (2) the Mapbox fix lands on main; then merge main into this branch. Re-running the checks or re-tagging me won't change the outcome until then.

[MelvinBot]

Both failing checks are unrelated to this PR (which only touches BankAccountSelector.tsx and CardSelector.tsx) — there's nothing to fix on this branch.

test (job 5) → ExportOnyxStateTest — the "Onyx key export coverage" test fails on the new key nvp_dismissedTrialPaymentReminder. That key was added to src/ONYXKEYS.ts on main today (via #84049) without being added to the export coverage buckets in tests/unit/ExportOnyxStateTest.ts. This PR's Jest job runs against a merge with main, so it inherits that breakage. It's failing the same way on other open PRs, and a fix is already up: #96037. Once that merges and main is merged into this branch, it'll pass.

build (Expensify Dev, Debug, true) (Remote Build iOS) — this was the MapboxMaps CocoaPods version conflict I flagged earlier. It's now fixed on main (main's iOS build is green again). This branch is just behind main; merging main in will clear it.

checklist (PR Author Checklist) — expected gate; needs the human co-author to fill in Tests/QA and tick the boxes.

Recommended: once #96037 lands, merge main into this branch — that pulls in both the Mapbox fix and the export-test fix, and everything should go green. All checks under this PR's own control (typecheck, ESLint, Oxfmt, the other 7 Jest shards, Storybook, dev/Android builds) are already passing.

Evidence

• Failing assertion: Onyx key export coverage › every ONYXKEYS value ... must be in one of the four buckets, uncovered key nvp_dismissedTrialPaymentReminder.
• NVP_DISMISSED_TRIAL_PAYMENT_REMINDER: 'nvp_dismissedTrialPaymentReminder' exists on main (added 09:11 UTC by Introduce free trial countdown pop-up #84049) but is not present on this PR branch's ONYXKEYS.ts — so it comes in via the PR↔main merge commit, not from this PR's diff.
• Same test fails with the same key on other open PRs (e.g. [No QA] Remove noisy hmmm log for missing personal details in workspace member lists #96030), confirming it's main-wide.
• Fix already open: [No QA] Fix failing test on main by bucketing the new trial payment reminder Onyx key #96037 ("Fix failing test on main by bucketing the new trial payment reminder Onyx key").
• main's "Remote Build iOS" runs are passing again as of ~09:16–09:21 UTC after the Mapbox version fix.

[mkhutornyi]

@MelvinBot add unit test. And pull main

[MelvinBot]

Done — added unit tests and merged main into the branch.

Unit tests — added tests/ui/BankAccountSelectorTest.tsx and tests/ui/CardSelectorTest.tsx, mirroring the existing InSelectorTest.tsx. Each file covers the 4 behaviors this PR changes:

1. The initially-selected item floats to the top section on first render of a long list.
2. Toggling another item after first render marks it selected in place — it does not jump to the top section.
3. While searching, an initially-selected item that still matches stays pinned; a pinned item that no longer matches is dropped (no duplicates).
4. On a short list (< STANDARD_LIST_ITEM_LIMIT), nothing is pinned — items stay in natural order.

Merged main — pulled in the Mapbox 10.3.2 fix and the nvp_dismissedTrialPaymentReminder ExportOnyxState bucketing fix I flagged earlier, so both of those unrelated failures should now clear.

Checks run locally

• npm test -- tests/ui/BankAccountSelectorTest.tsx tests/ui/CardSelectorTest.tsx → 8 passed (before and after the merge)
• npm run lint-changed → clean
• npm run typecheck-tsgo → clean
• npm run fmt on both files → no changes

The Tests/QA sections and the author checklist still need the human co-author to fill them in before marking this "ready for review".

[MelvinBot]

Update after the latest re-run: the two failing test jobs are both pre-existing failures on main, not caused by this PR. This PR's net diff (origin/main...HEAD) only touches the two Search selectors and their tests — nothing related to Onyx keys or the submit-migration-modal feature — so I'm reporting these rather than fixing them.

test (job 5) → tests/unit/ExportOnyxStateTest.ts — the "every ONYXKEYS value must be in one of the four buckets" test fails because NVP_SUBMIT_MIGRATION_MODAL_SHOWN (nvp_submitMigrationModalShown) exists in ONYXKEYS on main but was never added to the export buckets in ExportOnyxStateTest.ts. This is broken on main HEAD itself — whichever PR added that key needs to categorize it in the export test.

test (job 6) → tests/ui/components/SubmitPlanWelcomeModalTest.tsx — 3 failures in the same submit-migration-modal feature that just landed on main. Unrelated to this PR's changes.

checklist (PR Author Checklist) — expected; needs the human co-author to fill in Tests/QA and tick the boxes.

Everything under this PR's control is green: typecheck, ESLint, Oxfmt, Storybook, the iOS/dev builds, and the other 6 Jest shards all pass. (The earlier MapboxMaps iOS build failure I flagged has cleared now that main was merged in.)

Evidence

• PR changed files: BankAccountSelector.tsx, CardSelector.tsx, tests/ui/BankAccountSelectorTest.tsx, tests/ui/CardSelectorTest.tsx — no ONYXKEYS.ts, ExportOnyxStateTest.ts, or SubmitPlanWelcomeModal* changes.
• On origin/main (4d3a862): nvp_submitMigrationModalShown is present in ONYXKEYS.ts but absent from ExportOnyxStateTest.ts, so the bucket-coverage assertion fails there independently of this branch.
• Test failure diff: + "nvp_submitMigrationModalShown" as an uncovered top-level key.

[MelvinBot]

The two real failures (test (job 5) and test (job 6)) are not caused by this PR — they were introduced on main by #95099 ("[Submit] In-product modal…", merged ~09:56 UTC today), which this branch pulled in via the main merge (98524b7). This PR only touches BankAccountSelector.tsx / CardSelector.tsx and adds no Onyx keys or modal code, so I'm not pushing a fix — the fix belongs on main.

test (job 5) → tests/unit/ExportOnyxStateTest.ts — #95099 added ONYXKEYS.NVP_SUBMIT_MIGRATION_MODAL_SHOWN (nvp_submitMigrationModalShown) but never sorted it into an ExportOnyxState bucket. The coverage test requires every Onyx key to be in exactly one bucket, so it fails. The key is unbucketed on main today (src/ONYXKEYS.ts:529 present, nothing in src/libs/ExportOnyxState/common), so this fails on any branch built off current main.

test (job 6) → tests/ui/components/SubmitPlanWelcomeModalTest.tsx — this is #95099's own test file (3 SubmitPlanWelcomeModal cases failing). Also came in with the main merge and is unrelated to the selector changes.

Fix owner: #95099's author needs to bucket NVP_SUBMIT_MIGRATION_MODAL_SHOWN in src/libs/ExportOnyxState/common and green up the SubmitPlanWelcomeModal tests on main. Once that lands, merge main into this branch again and both will clear.

checklist is the standard PR Author Checklist gate — it just needs the human co-author to fill in the Tests/QA sections and tick the boxes; not something I fix.

Everything under this PR's control is green — typecheck, ESLint, Oxfmt, unit test shards 1–4/7–8 (including this PR's own new BankAccountSelector/CardSelector tests), Storybook, and the iOS/dev builds all pass. The two Android builds are still running but passed on the previous run of the identical selector code.

Evidence

• This PR's diff touches only BankAccountSelector.tsx and CardSelector.tsx (plus their unit tests) — no ONYXKEYS, no ExportOnyxState, no SubmitPlanWelcomeModal.
• origin/main (4d3a862) has NVP_SUBMIT_MIGRATION_MODAL_SHOWN: 'nvp_submitMigrationModalShown' in src/ONYXKEYS.ts:529 but no matching entry anywhere under src/libs/ExportOnyxState/.
• [Submit] In-product modal for existing "Get paid back" intent users (Wave 4) #95099's diff adds the key and the SubmitPlanWelcomeModalTest.tsx file, with no ExportOnyxState bucket change.

[mkhutornyi]

@MelvinBot Update PR title and Explanation of Change based on latest changes

[MelvinBot]

Updated the PR title and Explanation of Change to match the latest changes.

• Title → "Pin initially-selected items to the top of long BankAccount and Card filter lists" (reflects that pinning is now gated on list length).
• Explanation of Change → replaced the stale note that said the < 12 gate "still needs to be applied". It now describes the applied behavior: pinning only kicks in when the list has at least CONST.STANDARD_LIST_ITEM_LIMIT (12) items, mirroring the shared moveInitialSelectionToTop gate, and short lists stay in natural order. Also documented the unit tests added for both selectors.

Everything else in the body (Tests, QA, checklist, screenshots) is unchanged; I also dropped a malformed leftover block at the very bottom (a stray duplicate checklist under a ### Screenshots/Videosundefined heading).

[mkhutornyi]

@MelvinBot update tests steps based on latest changes

[MelvinBot]

Both remaining test failures are unrelated to this PR and are pre-existing on main — I won't push a fix for them. (The earlier iOS build failure has since cleared.)

• test (job 5) → tests/unit/ExportOnyxStateTest.ts — fails because the Onyx key nvp_submitMigrationModalShown isn't in any of the export "buckets". That key was added on main (src/ONYXKEYS.ts:529) without being bucketed, so the test fails on main too.
• test (job 6) → tests/ui/components/SubmitPlanWelcomeModalTest.tsx — 3 failures in the Submit-plan welcome/migration-modal flow, the same feature as above. Also unrelated to this PR.
• checklist (PR Author Checklist) — expected; needs the human co-author to fill in the Tests/QA sections and tick the boxes.

This PR only touches the two Search filter selectors and their new tests, and its own tests pass: tests/ui/BankAccountSelectorTest.tsx and tests/ui/CardSelectorTest.tsx both PASS. The two failing suites both concern the submitMigrationModal / SubmitPlanWelcomeModal feature, which this PR doesn't touch.

Evidence

• PR files: BankAccountSelector.tsx, CardSelector.tsx, tests/ui/BankAccountSelectorTest.tsx, tests/ui/CardSelectorTest.tsx — none reference ONYXKEYS, submitMigrationModal, or SubmitPlanWelcomeModal.
• ExportOnyxStateTest output: uncoveredTopLevel = ["nvp_submitMigrationModalShown"] — a key present in ONYXKEYS but not in any export bucket.
• On origin/main (4d3a862), NVP_SUBMIT_MIGRATION_MODAL_SHOWN is referenced only in ONYXKEYS.ts, CONST, SubmitPlanWelcomeModalGuard.ts, and User.ts — not in the export-state bucketing, so the coverage test fails on main.
• PR's own tests: PASS tests/ui/BankAccountSelectorTest.tsx, PASS tests/ui/CardSelectorTest.tsx.

[MelvinBot]

Updated the Tests, Offline tests, and QA Steps sections in the PR description to reflect the list-length gate that was added.

The key change: pinning only kicks in when the list has ≥ STANDARD_LIST_ITEM_LIMIT (12) items, so the steps now split into two cases:

• Long list (≥ 12 items) — pre-selected items float to the top on first render, a post-render toggle updates in place (no jump between sections), and searching keeps a matching pinned item while dropping one that no longer matches.
• Short list (< 12 items) — nothing is pinned; every item stays in its natural order with the selected ones simply marked in place.

I left the // TODO: The human co-author must fill out... notes and the checkboxes untouched — those still need the human co-author to fill in and tick before marking the PR "ready for review".

[mkhutornyi]

@codex review

[mkhutornyi]

@MelvinBot review

[MelvinBot]

All three failing checks are unrelated to this PR — there's nothing here for me to fix. The two real test failures are pre-existing on main, introduced by #95099 (the submit in-product modal).

• test (job 5) → tests/unit/ExportOnyxStateTest.ts — "every ONYXKEYS value must be in one of the four buckets" fails because 3 newly-added Onyx keys aren't categorized. This PR adds zero Onyx keys.
• test (job 6) → tests/ui/components/SubmitPlanWelcomeModalTest.tsx — a modal test added by that same PR. This PR doesn't touch it or anything it imports.
• checklist (PR Author Checklist) — the standard author-checklist gate; not a code failure.

This PR changes only BankAccountSelector.tsx, CardSelector.tsx, and their two new test files — and those new tests pass. Per policy I don't fix unrelated failures; the fix belongs on main (a follow-up to #95099). Once that lands, merge main into this branch and the checks will clear.

Evidence

• PR touches only: src/components/Search/FilterComponents/BankAccountSelector.tsx, src/components/Search/FilterComponents/CardSelector.tsx, tests/ui/BankAccountSelectorTest.tsx, tests/ui/CardSelectorTest.tsx.
• git diff between this branch (6fc780a) and latest main (4d3a862) for ExportOnyxStateTest.ts, src/ONYXKEYS.ts, and SubmitPlanWelcomeModalTest.tsx is empty — identical to main, so the failures reproduce on main unchanged.
• The most recent main commit touching src/ONYXKEYS.ts and the one that added SubmitPlanWelcomeModalTest.tsx both come from [Submit] In-product modal for existing "Get paid back" intent users (Wave 4) #95099.

[MelvinBot]

Reviewed the diff — the approach is sound and matches the already-shipped InSelector pattern. Snapshotting the selection with useInitialValue and keying section membership on the snapshot while each row's checkbox keeps reading live value is exactly the right way to stop rows from jumping between sections, and the >= STANDARD_LIST_ITEM_LIMIT gate mirrors moveInitialSelectionToTop. I confirmed the selectors remount when the active filter changes (they're swapped by component type in FilterComponents/index.tsx:109), so the snapshot correctly reflects the selection each time the filter is reopened. Typecheck, lint, and the new unit tests all pass. 👍

A couple of minor, non-blocking points:

1. CardSelector pins on a different count than it shows the search box on. The pin gate counts individual + closed cards (CardSelector.tsx:80), but the search-input gate counts individual cards only (CardSelector.tsx:71). So with e.g. 10 individual + 3 closed cards you'd get a pinned top section but no search box. Counting the total matches the shared helper's contract, so this is defensible — just flagging it's an intentional-looking asymmetry (BankAccountSelector uses the same count for both). Worth a conscious decision.

2. Tiny DRY nit (optional). In BankAccountSelector, shouldPinInitialSelection (L108) is byte-identical to shouldShowSearchInput (L99) — could reuse the one variable. And since both selectors now carry near-identical inline pinning logic (a section-grouped variant of moveInitialSelectionToTop), a small shared helper would prevent the two from drifting apart later. Not required for this PR.

Behavior note (looks intentional, just confirming): deselecting an initially-selected row keeps it in the pinned top section, unchecked, until the filter is reopened — consistent with "don't make rows jump between sections."

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6fc780acf3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Disable auto-scroll when new card selections stay in place

When selecting an unselected card, this new grouping now leaves the row in unselectedIndividualCardsData, but SelectionListWithSections still auto-scrolls multi-section multi-select lists to index 0 before calling onSelectRow (BaseSelectionListWithSections.tsx:132-135) unless shouldPreventAutoScrollOnSelect is set. In long card lists, choosing a card below the fold will therefore jump the viewport to the top even though the row no longer moves there, which preserves the original disruptive jump in a different form.

Useful? React with 👍 / 👎.

[mkhutornyi]

Fixed by setting shouldPreventAutoScrollOnSelect = true

[chatgpt-codex-connector]

Disable auto-scroll when new bank selections stay in place

When selecting an unselected bank account, this new grouping now leaves the row in unselectedOpenData/unselectedClosedData, but SelectionListWithSections still auto-scrolls multi-section multi-select lists to index 0 before calling onSelectRow (BaseSelectionListWithSections.tsx:132-135) unless shouldPreventAutoScrollOnSelect is set. In bank-account lists, choosing an account below the fold will therefore jump the viewport to the top even though the row no longer moves there, so the no-jump behavior is not actually achieved.

Useful? React with 👍 / 👎.

[mkhutornyi]

Fixed by setting shouldPreventAutoScrollOnSelect = true

[mkhutornyi]

@MelvinBot pass shouldClearInputOnSelect=false, shouldUpdateFocusedIndex=true, shouldPreventAutoScrollOnSelect=true in both components.
And update unit tests

[MelvinBot]

Marked this PR as ready for review ✅

All completed checks are green — the earlier MapboxMaps and ExportOnyxState failures cleared once main was merged in. A few checks are still running (typecheck, test (job 2), and the perf-test jobs), but none are failing.

[github-actions]

❌ CONSISTENCY-3 (docs)

shouldPinInitialSelection computes the exact same expression (openItems.length + closedItems.length >= CONST.STANDARD_LIST_ITEM_LIMIT) that shouldShowSearchInput already computes a few lines above. This duplicates the same list-length gate in two named constants, so any future change to the threshold logic has to be made in both places.

Reuse the already-computed value instead of recalculating it:

const shouldShowSearchInput = openItems.length + closedItems.length >= CONST.STANDARD_LIST_ITEM_LIMIT;
// ...
const shouldPinInitialSelection = shouldShowSearchInput;

or, if the two concepts should stay distinct, hoist the shared comparison into one named boolean (e.g. isLongList) that both derive from.

---

Reviewed at: 7e11554 | Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

[MelvinBot]

Done in 7924ff1 — shouldPinInitialSelection now just aliases the already-computed shouldShowSearchInput instead of recomputing openItems.length + closedItems.length >= CONST.STANDARD_LIST_ITEM_LIMIT, so the list-length gate lives in one place. Kept the distinct name since it documents the pinning intent at its use sites.

[github-actions]

❌ CONSISTENCY-3 (docs)

shouldPinInitialSelection computes the exact same expression (individualCardsSectionData.length + closedCardsSectionData.length >= CONST.STANDARD_LIST_ITEM_LIMIT) that shouldShowSearchInput already computes on the line above. This duplicates the same list-length gate in two named constants, so the threshold logic must be kept in sync in two places.

Reuse the already-computed value instead of recalculating it:

const shouldShowSearchInput = individualCardsSectionData.length + closedCardsSectionData.length >= CONST.STANDARD_LIST_ITEM_LIMIT;
// ...
const shouldPinInitialSelection = shouldShowSearchInput;

or, if the two concepts should stay distinct, hoist the shared comparison into one named boolean (e.g. isLongList) that both derive from.

---

Reviewed at: 7e11554 | Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.

[MelvinBot]

Done in 7924ff1 — shouldPinInitialSelection now just aliases the already-computed shouldShowSearchInput instead of recomputing individualCardsSectionData.length + closedCardsSectionData.length >= CONST.STANDARD_LIST_ITEM_LIMIT, so the list-length gate lives in one place. Kept the distinct name since it documents the pinning intent at its use sites.

[mkhutornyi]

@MelvinBot address #96031 (comment) and #96031 (comment)

[melvin-bot]

@mkhutornyi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[github-actions]

🚧 marcaaron has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #96031.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-e13a33f4e01-28deac6-40b45cbc90fad5c63aa80dbdb5efeb02999a50de/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-e13a33f-28deac6-48ccef668ade6ce72340fd44bf1d3c686e9934ab/index.html

Web 🕸️
https://96031.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/marcaaron in version: 9.4.36-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

🤖 I reviewed the changes in this PR against Expensify's help site files under docs/articles, and no help site changes are required.

Why: This PR is a purely internal UI-behavior fix. It changes how the Bank account and Card filters (under Search filters) order their rows — snapshotting which items were selected when the filter first opened so pre-selected items stay pinned to the top of long lists (12+ items) and don't jump between sections when toggled. It adds no new user-facing feature, setting, or workflow, and doesn't rename or relabel anything.

The help articles document what the Search filters do, not the row-ordering/pinning mechanics of individual filter lists, so there's nothing to update. Since no changes are required, no draft help site PR was created.

mkhutornyi, if you believe a help site update is warranted here, let me know and I'll draft one.

[kavimuru]

@marcaaron @parasharrajat Applause can't connect 12 bank accounts. Could this be verified internally?

[mkhutornyi]

can't connect 12 bank accounts. Could this be verified internally?

yes, just test Card list. The same logic applied to Bank account

[OSBotify]

🚀 Deployed to staging by https://github.com/marcaaron in version: 9.4.38-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	cancelled 🔪
🍎 iOS 🍎	cancelled 🔪

[MelvinBot]

🤖 I reviewed the changes in this PR against the help site articles under docs/articles. No help site changes are required.

Why: This PR is a purely internal UX/ordering refinement. It snapshots the initially-selected items when the Bank account and Card filters first open so they stay floated to the top of long lists (≥ 12 items), and prevents toggled rows from jumping between sections. It introduces no new feature, tab, setting, button, or copy.

The public help articles that touch Search filtering — Use Search Operators to Filter and Analyze and Search and Download Expenses — document filter syntax and workflows. Neither describes the internal ordering of items within a filter's selection list, so nothing there becomes inaccurate as a result of this change. No draft PR was created.

@mkhutornyi, please confirm you agree no help site updates are needed here. If you believe a doc should call out this behavior, let me know and I'll draft the PR.

[OSBotify]

🚀 Deployed to staging by https://github.com/marcaaron in version: 9.4.40-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

🤖 I reviewed the changes in this PR against Expensify's help site files under App/docs/articles.

No help site changes are required.

This PR is a purely internal UI-ordering refinement of the Bank account and Card filters on the Search (Spend) page. It snapshots which accounts/cards were selected when a filter first opened so those items stay pinned to the top of long lists (12+ items) instead of jumping between sections when toggled. There is no new feature, no new setting, and no change to any feature name, tab, button label, or documented workflow.

The relevant help articles (e.g. Search-and-Download-Expenses.md, Use-Search-Operators-to-Filter-and-Analyze.md) describe what the filters do and how to use them — they do not document the internal sort/pin order of items within a filter list, which is the only behavior this PR touches. So no article becomes inaccurate as a result of this change.

No draft PR was created since there is nothing to update.

@mkhutornyi, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

[OSBotify]

🚀 Deployed to production by https://github.com/yuwenmemon in version: 9.4.40-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android