Repository navigation
Start chat - User not moved to the top after select #100325
Description
Activity
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/c01830d5100a1a68720b37fd98ee816acfb161024ff9067d0763edb951218adaProposal
TL;DR: this is not a bug — the behavior was removed on purpose. BrowserStack TC 3232 is out of date and should be updated, not "fixed" in code.
What is the root cause of that problem?
Nothing is broken. Selected users stopped moving to the top of the Start chat list deliberately, in Expensify/App#93077 (merged 2026-06-16), which was opened to fix #61414 — "Stop scrolling and jumping when selecting items in multi-select view." That PR removed the
scrollToIndex(0)call and stopped hoisting selected options into a top section. Expensify/App#95778 (merged 2026-08-10) carried the behavior into the shareduseSearchSelectorhook, which is what ships in 9.4.69-0.Today the page opts in explicitly at
src/pages/NewChatPage/index.tsx:132withshouldKeepSelectedInAvailableOptions: true, so a selected contact stays in Recents/Contacts in place and just gets markedisSelected. The top section is now reserved for invite-by-email contacts only.The behavior is also locked by a regression test named
should not move a selected user to the top of the list, which asserts exactly the scenario in this report.What changes do you think we should make in order to solve the problem?
No app code change. Update BrowserStack TC 3232 so its expected result matches shipped intent: the selected user stays in place and shows a selected state where it is, and the list does not scroll.
If product actually wants the old jump-to-top back, that is a product reversal of #61414, not a bug fix — it would require reverting two merged PRs and deleting three UI tests, and would re-break the still-open issue.
What alternative solutions did you explore? (Optional)
- Restore hoisting on Start chat only. Rejected — it directly contradicts [$250] Stop scrolling and jumping when selecting items in multi-select view #61414 and breaks the existing regression tests.
moveInitialSelectionToTop(src/libs/SelectionListOrderUtils.ts:3-22) — the compromise already used elsewhere: pin rows selected at mount, don't re-pin on toggle. It would not move a freshly tapped contact to the top, so it does not satisfy this report either.- Add a selected-count affordance instead. If the tester's real complaint was "I can't tell who I've picked" rather than ordering, a persistent selection summary would address that without reintroducing the jump.
Investigation details
Mechanism.
shouldKeepSelectedInAvailableOptionsshort-circuits the only filter that could pull selected rows out of the main list —src/hooks/useSearchSelector/base.ts:459-463. Because selected options stay inrecentReports/personalDetailsin their original relevance order, the row keeps its index and only its accessory changes.The top section at
src/pages/NewChatPage/index.tsx:186-197is filtered to!!option.isOptimisticAccount— only invited contacts created from the search term, which have no row in Recents/Contacts and would otherwise vanish when the search box clears. A real contact picked from the list never enters it.Not an outlier. The same pattern is used by the workspace invite page, room invite page, Search user filters, and Add Delegate. The money-request participant pages have not been migrated yet, which is why #61414 is still open.
Alternative explanations ruled out. There is no
shouldShowSelectedItemsOnTopprop anywhere insrc/;BaseSelectionListnever reorders by selection, andorderOptionsinOptionsListUtilshas noisSelectedterm. So there is no ordering path that could be silently failing — the list renders exactly the sections the page builds.Live verification was blocked. The web session handed to the tester rendered a blank page, so the flow could not be driven end to end. The conclusion rests on code plus the existing UI tests, which are deterministic for this behavior.
Possibly related: #61414 (open) — the issue whose fix produced this behavior. Any change here needs to be reconciled with it.
Next Steps for Contributor+ team:
To accept:@MelvinBot implement [this](https://github.com/Expensify/App/issues/100325)to create a draft PR.
To refine:@MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.
Triggered auto assignment to Contributor-plus team member for initial proposal review - @bernhardoj (
External)Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.
As Melvin said, this is the expected behavior now. @gleitebr we need to update the TC here.
@bernhardoj Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@bernhardoj Eep! 4 days overdue now. Issues have feelings too...
@bernhardoj 6 days overdue. This is scarier than being forced to listen to Vogon poetry!
@bernhardoj 10 days overdue. I'm getting more depressed than Marvin.
@lanitochka17 this is expected. Can we update the TC instead and close this?
Reacted by Matt Allen@bernhardoj Updated the referenced test case
Reacted by Matt AllenThanks!
Thx! Closing
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.
Version Number: 9.4.69-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176682/test-cases?p=1&q=3232
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Ventura / Chrome
App Component: Other
Action Performed:
Expected Result:
Selected user moved to the top of the list
Actual Result:
Selected user stayed on his position
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7250264_1788450773864.REC-20260903184832.mp4
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @bernhardoj