Fix scroll/reorder jump when selecting in the Search In filter by MelvinBot · Pull Request #95321 · Expensify/App

MelvinBot · 2026-07-04T19:22:04Z

Explanation of Change

The In search filter (InSelector.tsx) split its list into a top "selected" section and a main section by keying on the live value. So the moment you selected an item, it was pulled out of the main list and jumped up into the selected section at the top — scrolling the view and disorienting multi-select, exactly like the sibling issue fixed for the People pickers in #94609.

This PR fixes that jump, and keeps the pinned section consistent while searching:

Snapshot the reports that were already selected when the filter first opened (useInitialValue). Only these are floated to the top, so items toggled during the session keep their position instead of being re-pinned.
Gate the top section on the unfiltered list size (CONST.STANDARD_LIST_ITEM_LIMIT, 12) so pre-selected items are only floated to the top on a large list — and so typing a search value doesn't flip the pinning off the moment the filtered results dip below the threshold. Short lists show everything in place.
Keep the pinned reports at the top whether or not a search value is entered. When a term is typed, only the pinned reports that still match the filtered results stay at the top; non-matching ones are dropped.
Mark rows selected in place (checkmark toggles) without reordering; drop the pinned reports from the main section to avoid duplicates.

Result: selecting an item no longer scrolls/reorders the list, pre-selected items stay grouped at the top on long lists, and that grouping now persists (for the matching items) as you type in the search box — keeping the behavior consistent per this discussion.

Verified on web (dev NewDot): selecting a mid-list item keeps it in place and just adds a checkmark — no jump.

Before selecting

After selecting (item stays put, checked)

A regression test (tests/ui/InSelectorTest.tsx) covers: pinning the initial selection to the top of a long list, keeping a toggled row in place (no jump), keeping a matching pinned report at the top while searching (and dropping a non-matching one), and no pinning on a short list.

Fixed Issues

$ #61414

Tests

Navigate to Reports (Search).
Click the Filters pill > Type and select Chat or Task, then open the In filter.
On an account with a long list of chats, scroll down and select an item that is not at the top.
Verify the list does not scroll/reorder — the item stays in place and gains a checkmark.
Go back to another filter and return to In; verify pre-selected items are grouped at the top (long list only).

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

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

- [x] I verified that similar component doesn't exist in the codebase - [x] I verified that all props are defined accurately and each prop has a `/** comment above it */` - [x] I verified that each file is named correctly - [x] 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 - [x] I verified that the only data being stored in component state is data necessary for rendering and nothing else - [x] 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 - [x] 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) - [x] 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`) - [x] I verified that all JSX used for rendering exists in the render method - [x] 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

Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

MelvinBot · 2026-07-04T19:32:07Z

🤖 Fixed the failing check and pushed to the branch.

Root cause: The new regression test tests/ui/InSelectorTest.tsx:55 used a narrowing type assertion (... as Array<{data: SectionData[]}>) on the mocked SelectionListWithSections props, which trips the @typescript-eslint/no-unsafe-type-assertion rule. That's what the pending ESLint check would have failed on.

Fix: Dropped the assertion and the now-unused SectionData type, and read the sections directly with a ?? [] fallback (the test only reads keyForList/isSelected, both present on the inferred item type). Verified locally:

✅ ESLint (lint.sh) — clean
✅ typecheck-tsgo — no errors
✅ tests/ui/InSelectorTest.tsx — 3/3 passing
✅ oxfmt — no changes

Note: the PR Author Checklist / checklist failure is the human checkbox check (in the ignore list), not a code issue — it'll clear when the checklist is completed.

mkhutornyi · 2026-07-05T09:30:59Z

@MelvinBot pass below to SelectionListWithSections:

shouldClearInputOnSelect=false
shouldUpdateFocusedIndex=true
shouldPreventAutoScrollOnSelect=true

…tAutoScrollOnSelect to SelectionListWithSections Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

MelvinBot · 2026-07-05T09:35:25Z

Done ✅ — passed the three props to SelectionListWithSections in InSelector.tsx:

shouldClearInputOnSelect={false}
shouldUpdateFocusedIndex
shouldPreventAutoScrollOnSelect

Formatting, lint, and typecheck all pass. Pushed to claude-inSelectorScrollJump.

mkhutornyi · 2026-07-05T09:36:27Z

@MelvinBot based on #61414 (comment), keep pinned items at the top when input any value on search for consistency

Gate pinning on the unfiltered list size so typing a search value doesn't collapse the pinned section, and keep only the pinned reports that still match the filtered results at the top for consistency. Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

MelvinBot · 2026-07-05T09:48:41Z

Done — pushed 7fcde2b. Pinned items now stay at the top when you type a search value, matching shawnborton's "keep it pinned at the top for consistency".

What changed in InSelector.tsx:

Previously, typing a search value collapsed the pinned top section (the non-empty-term branch fell back to formatSectionsFromSearchTerm, which drops selected rows that are already in the results). Now the pinned section is built the same way whether or not a term is entered, so pinned items stay grouped at the top.
While searching, only the pinned reports that still match the current results are surfaced (non-matching ones are dropped), and they're removed from the main list to avoid duplicates.
The "is the list long enough to pin?" check now uses the unfiltered list size instead of the filtered one, so the pinned section doesn't flip off the moment typing narrows the results below the 12-item threshold. On an empty search these two counts are identical, so no-search behavior is unchanged.

Short lists still show everything in place (no pinning), same as before.

Tests: added a case to InSelectorTest.tsx covering a search that keeps a matching pinned report at the top and drops a non-matching one. All 4 tests pass. Lint, react-compiler-compliance-check, and typecheck (tsgo) are clean.

MelvinBot · 2026-07-05T09:49:01Z

⚠️ MelvinBot CI Fix Loop Detected

MelvinBot has made 5 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR.

Next steps: A human should review the recent commits and resolve the conflicting CI errors manually.

mkhutornyi · 2026-07-05T10:14:14Z

@codex review

mkhutornyi · 2026-07-05T10:14:17Z

@MelvinBot review

MelvinBot · 2026-07-05T10:16:45Z

Review

Verdict: Logic looks correct and CI is green (the only red check is PR Author Checklist, which is the human checklist, not a code failure). A few things to verify before merge — no blockers.

What the PR does well

Snapshotting the initial selection via useInitialValue is the right fix for the scroll/jump: items toggled during the session keep their position, only pre-selected items float up.
Gating on the unfiltered list size (defaultOptions.recentReports.length) is correct — it keeps the pinned section from collapsing the moment a search narrows results below the 12‑item threshold, which is what makes the pinned-while-searching behavior consistent. Since this selector passes no maxRecentReportsToShow, that count equals the filtered count on an empty search, so no-search behavior is unchanged.
Dropping pinned reports from the main section by pinnedReportIDSet avoids duplicates cleanly, and the tests cover the meaningful cases (pin on long list, no-jump on toggle, pin-while-searching + drop non-matching, no-pin on short list).

Things to verify / minor points

Pinned-while-searching relies on membership in chatOptions.recentReports (here). This works because the recent-reports list isn't capped here. If a maxRecentReportsToShow cap is ever added to this selector's filterAndOrderOptions call, a pinned report that matches the term but falls outside the cap would silently drop from the top. Fine today — just a note for future changes.
Only recentReports are rendered; chatOptions.personalDetails are never pushed into a section. This is pre-existing (unchanged by this PR), but worth confirming it's intentional for the In filter.
Manual QA still needed. The Tests/QA sections are still TODO placeholders. Since this is an interaction change on a shared component, please verify on a real long-list (High Traffic) account: (a) selecting a mid-list item doesn't scroll/reorder, (b) pinned items stay grouped at the top while typing and non-matching ones drop, (c) short lists are unchanged — and ideally sanity-check native/mobile, not just web.

Unit tests (4), ESLint, react-compiler-compliance-check, and typecheck all pass locally and in CI.

chatgpt-codex-connector · 2026-07-05T10:19:44Z

Codex Review: Didn't find any major issues. 🎉

Reviewed commit: 7fcde2bf34

ℹ️ 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".

MelvinBot · 2026-07-05T10:23:31Z

Regression review

No compile/type/test regressions — typecheck (tsgo), lint, react-compiler-compliance-check, and the 4 InSelectorTest cases are all green. The findings below are behavioral/consistency risks worth a look before merge, ranked by severity.

1. Reimplements the shared pinning hook instead of reusing it (medium)

This PR hand-rolls the "snapshot the initial selection → float to a top section on long lists → keep toggles in place → honor the search term" logic inline in InSelector.tsx:143-170. That exact pattern already exists as useFrozenPreSelection and is used by ~10 pickers (e.g. CountrySelectionList, WorkspaceMembersSelectionList), while the sibling filter in this same folder, UserSelector.tsx:68-71, uses the companion moveInitialSelectionToTop util.

Not a runtime bug, but it's the highest-value fix: adopting useFrozenPreSelection (its shouldRenderPinned predicate is built for the search case — see #2) would delete most of this block and keep the three In/From/To-style filters consistent.

2. A pinned report that matches the search but isn't in the filtered results gets dropped (low, theoretical)

During search the top section is filtered to matchedReportIDs, which is derived only from chatOptions.recentReports (InSelector.tsx:154-155). If a pinned report matches the typed term but isn't returned by the filter, it disappears entirely. On main, formatSectionsFromSearchTerm surfaced such rows via selectedParticipantsWithoutDetails, and useFrozenPreSelection handles it via shouldRenderPinned (which renders from the frozen snapshot, "needed when pinned rows may not appear in the input sections"). In practice this is hard to hit — filterAndOrderOptions here is called with no maxRecentReportsToShow and selection only marks rows (doesn't drop them), so a matching selected report should stay in recentReports — but it's a real behavioral narrowing vs main.

3. The pin/no-pin gate is recomputed live, not frozen (low)

shouldMoveSelectedToTop reads defaultOptions.recentReports.length on every render (InSelector.tsx:145). If reports stream in and the count crosses STANDARD_LIST_ITEM_LIMIT (12) after mount, the pinned section can pop in and reflow the list. useFrozenPreSelection deliberately freezes this decision at first ready render. (This pre-dates the search fix; flagging for awareness.)

4. A deselected pre-selected row stays pinned-at-top but unchecked (low, likely intended)

On a long list the top section renders every initialValue id regardless of live selection, with isSelected: value.includes(id) (InSelector.tsx:156). Deselecting a pre-selected item leaves an unchecked row pinned at the very top until reopen. This is the intended "don't jump" tradeoff (same as the shared hook), just worth a conscious QA confirmation.

5. New selection-list props change multi-select-during-search UX (low)

shouldClearInputOnSelect={false}, shouldUpdateFocusedIndex, and shouldPreventAutoScrollOnSelect (InSelector.tsx:224-226) mean the search term now persists after each selection and the list no longer auto-scrolls. Core to the fix, but a visible interaction change — worth exercising the "search → select several → verify no scroll/no input clear" flow in QA.

Bottom line: nothing here blocks correctness, but I'd strongly consider #1 (reuse useFrozenPreSelection) since it subsumes #2 and #3 and aligns In with the other filters. Happy to draft that refactor — reply @MelvinBot implement this if you'd like me to.

Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

MelvinBot · 2026-07-05T10:41:40Z

Done — removed the https://github.com/Expensify/App/issues/61414 references from both code comments in InSelector.tsx. The comments still explain the intent; they just no longer link back to the issue. Pushed as abf29a9. Format and lint pass.

mkhutornyi · 2026-07-05T11:13:04Z

@MelvinBot update Explanation of Change based on latest code changes

MelvinBot · 2026-07-05T11:15:50Z

Updated the Explanation of Change in the PR description to reflect the latest code. Key additions:

Now documents that the "long list" gate uses the unfiltered list size, so typing a search value doesn't collapse the pinned section once results dip below the 12-item threshold.
Adds the new behavior: pinned reports stay at the top while searching, with only the ones still matching the filtered results kept (non-matching ones dropped) — the consistency point from shawnborton's comment.
Notes the extra regression-test case in tests/ui/InSelectorTest.tsx covering the search scenario, and added a matching manual test step.

The human co-author still owns the Tests/QA result checkboxes and screenshots.

mkhutornyi · 2026-07-05T11:20:00Z

Details

Explanation of Change

The In search filter (InSelector.tsx) split its list into a top "selected" section and a main section by keying on the live value. So the moment you selected an item, it was pulled out of the main list and jumped up into the selected section at the top — scrolling the view and disorienting multi-select, exactly like the sibling issue fixed for the People pickers in #94609.

This PR fixes that jump, and keeps the pinned section consistent while searching:

Snapshot the reports that were already selected when the filter first opened (useInitialValue). Only these are floated to the top, so items toggled during the session keep their position instead of being re-pinned.
Gate the top section on the unfiltered list size (CONST.STANDARD_LIST_ITEM_LIMIT, 12) so pre-selected items are only floated to the top on a large list — and so typing a search value doesn't flip the pinning off the moment the filtered results dip below the threshold. Short lists show everything in place.
Keep the pinned reports at the top whether or not a search value is entered. When a term is typed, only the pinned reports that still match the filtered results stay at the top; non-matching ones are dropped.
Mark rows selected in place (checkmark toggles) without reordering; drop the pinned reports from the main section to avoid duplicates.

Result: selecting an item no longer scrolls/reorders the list, pre-selected items stay grouped at the top on long lists, and that grouping now persists (for the matching items) as you type in the search box — keeping the behavior consistent per this discussion.

Verified on web (dev NewDot): selecting a mid-list item keeps it in place and just adds a checkmark — no jump.

Before selecting

After selecting (item stays put, checked)

A regression test (tests/ui/InSelectorTest.tsx) covers: pinning the initial selection to the top of a long list, keeping a toggled row in place (no jump), keeping a matching pinned report at the top while searching (and dropping a non-matching one), and no pinning on a short list.

Fixed Issues

$ #61414

Tests

Navigate to Reports (Search).
Click the Filters pill > Type and select Chat or Task, then open the In filter.
On an account with a long list of chats, scroll down and select an item that is not at the top.
Verify the list does not scroll/reorder — the item stays in place and gains a checkmark.
Go back to another filter and return to In; verify pre-selected items are grouped at the top (long list only).

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

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

@MelvinBot please set the PR body to the content in the details section above

MelvinBot · 2026-07-05T11:25:34Z

✅ Done — I've set the PR description to the content you provided.

mkhutornyi · 2026-07-05T11:27:35Z

@MelvinBot mark as ready for review

melvin-bot · 2026-07-05T11:29:10Z

@parasharrajat @ChavdaSachin @mkhutornyi One of you needs to 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]

mkhutornyi · 2026-07-05T11:29:10Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible 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 checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (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 verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- 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)
- Any 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)
- All JSX used for rendering exists in the render method
- The 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
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 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.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this 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 have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

android.mov

Android: mWeb Chrome

iOS: HybridApp

ios.mov

iOS: mWeb Safari

MacOS: Chrome / Safari

web.mov

MelvinBot · 2026-07-05T11:29:12Z

Done — marked this PR as ready for review. 🚀

Note: the Tests and QA Steps sections in the PR description still have // TODO placeholders for the human co-author to fill in before merge.

MelvinBot · 2026-07-05T11:33:31Z

Done ✅ — checked off the remaining 10 unchecked items in the PR Author Checklist (the component code-review attestations), per your confirmation that you verified them.

The checklist now has no unchecked boxes.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: abf29a9ccc

ℹ️ 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 · 2026-07-05T11:34:37Z

+        // decision doesn't flip as the user types, and key the pinned section on the snapshot (instead of the live
+        // `value`) so items toggled during this session stay put.
+        const shouldMoveSelectedToTop = defaultOptions.recentReports.length >= CONST.STANDARD_LIST_ITEM_LIMIT;
+        const pinnedReportIDs = shouldMoveSelectedToTop ? initialValue : [];


Keep newly selected search-only reports visible

With pinnedReportIDs based only on initialValue, reports selected after opening the filter are rendered only if they remain in chatOptions.recentReports. useFilteredOptions switches back to the capped non-search report set when the search box is cleared, so a user can search for an older/non-recent chat, select it, clear the search, and that selected chat disappears from both sections even though value still contains its ID; the filter can then be applied with a hidden in: constraint or require re-searching to deselect it.

Useful? React with 👍 / 👎.

It's pre-existing bug happening on production, not caused by this PR so out of scope.

Repro step:

Select any item from server results

Observe in filter pill shows

Save search

Clear cache and restart

Go to saved search

Observe in filter pill doesn't show <--- bug

Search for the selected item and get server results

Observer selected item is not checked off <--- bug

Go to another tab and back to saved search

Observe in filter pill shows and selected item is checked off

Screen.Recording.2026-07-05.at.12.44.57.PM.mov

MelvinBot and others added 2 commits July 4, 2026 19:00

Fix scroll/reorder jump when selecting in Search In filter

db66a96

Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

Add regression test for In filter scroll/reorder jump

0f9386a

Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

MelvinBot assigned mkhutornyi Jul 4, 2026

MelvinBot requested a review from a team July 4, 2026 19:22

MelvinBot mentioned this pull request Jul 4, 2026

[Due for payment 2026-07-07] [$250] Stop scrolling and jumping when selecting items in multi-select view #61414

Open

16 tasks

Fix ESLint no-unsafe-type-assertion in InSelector test

55b5b57

Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

Pass shouldClearInputOnSelect, shouldUpdateFocusedIndex, shouldPreven…

e8b6bdc

…tAutoScrollOnSelect to SelectionListWithSections Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

Remove issue-link references from InSelector code comments

abf29a9

Co-authored-by: mkhutornyi <mkhutornyi@users.noreply.github.com>

MelvinBot marked this pull request as ready for review July 5, 2026 11:29

MelvinBot requested a review from a team as a code owner July 5, 2026 11:29

melvin-bot Bot requested review from ChavdaSachin and trjExpensify July 5, 2026 11:29

melvin-bot Bot requested review from a team, mkhutornyi and parasharrajat and removed request for a team July 5, 2026 11:29

melvin-bot Bot requested review from joekaufmanexpensify and removed request for a team July 5, 2026 11:29

mkhutornyi approved these changes Jul 5, 2026

View reviewed changes

melvin-bot Bot requested review from francoisl and marcaaron July 5, 2026 11:29

chatgpt-codex-connector Bot reviewed Jul 5, 2026

View reviewed changes

Uh oh!

Conversation

MelvinBot commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

MelvinBot commented Jul 4, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Uh oh!

MelvinBot commented Jul 5, 2026

Review

Uh oh!

chatgpt-codex-connector Bot commented Jul 5, 2026

Uh oh!

MelvinBot commented Jul 5, 2026

Regression review

1. Reimplements the shared pinning hook instead of reusing it (medium)

2. A pinned report that matches the search but isn't in the filtered results gets dropped (low, theoretical)

3. The pin/no-pin gate is recomputed live, not frozen (low)

4. A deselected pre-selected row stays pinned-at-top but unchecked (low, likely intended)

5. New selection-list props change multi-select-during-search UX (low)

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Uh oh!

melvin-bot Bot commented Jul 5, 2026

Uh oh!

mkhutornyi commented Jul 5, 2026

Reviewer Checklist

Screenshots/Videos

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

MelvinBot commented Jul 5, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 5, 2026

Choose a reason for hiding this comment

Uh oh!

mkhutornyi Jul 5, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot commented Jul 4, 2026 •

edited

Loading