Workspace Members - Search field clears after selecting a member from the filtered invite list

[yuwenmemon]

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

Action Performed:

1. Go to a workspace's Members page (e.g. staging.new.expensify.com/workspaces/<policyID>/members).
2. Click Invite member.
3. In the "Name, email, or phone number" field, type a search term (e.g. "yuwen") to filter the contacts list.
4. Click the checkbox next to any filtered contact (e.g. Yuwen Corp, yuwen@expensicorp.com) to select them.

Expected Result:

The search field retains the typed search term and the contacts list stays filtered, allowing more matching contacts to be selected without re-typing.

Actual Result:

As soon as a contact is selected, the search field is cleared and the full, unfiltered contacts list is shown instead. The user has to retype the original search term to keep filtering.

Workaround:

Retype the search term after each selection.

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

Kapture.2026-07-28.at.13.10.20.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082202941705937412
• Upwork Job ID: 2082202941705937412
• Last Price Increase: 2026-07-28

[MelvinBot]

Proposal

What is the root cause of that problem?

The invite members page renders its list with SelectionListWithSections and canSelectMultiple. When a row is selected, selectRow clears the search input:

if (shouldShowTextInput && shouldClearInputOnSelect) {
    textInputOptions?.onChangeText?.('');
}

BaseSelectionListWithSections.tsx:141-143

shouldClearInputOnSelect defaults to true in this component (BaseSelectionListWithSections.tsx:80), and DynamicWorkspaceInvitePage.tsx doesn't override it. Since the page wires onChangeText: setSearchTerm on a controlled input, every selection calls setSearchTerm(''), wiping the search term and unfiltering the list — exactly the reported behavior.

Note the two SelectionList families have opposite defaults for this prop: the older SelectionList defaults it to false (BaseSelectionList.tsx:99), so pages on the old component never cleared the search. Migrating the invite page to SelectionListWithSections silently flipped that default to true.

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

Pass shouldClearInputOnSelect={false} to the <SelectionListWithSections> in DynamicWorkspaceInvitePage.tsx, so the typed search term is retained across selections. This matches how NewChatPage's multi-select invite list already does it (NewChatPage/index.tsx:509).

Supporting evidence & data flow

• Type in field → onChangeText=setSearchTerm → controlled value=searchTerm re-renders, list filters on debouncedSearchTerm.
• Click a filtered row → selectRow enters the canSelectMultiple branch → shouldShowTextInput=true and shouldClearInputOnSelect (default true) → textInputOptions.onChangeText('') = setSearchTerm('').
• searchTerm becomes '' → controlled input empties, list unfilters → user must retype.

The toggleSelection logic in usePersonalDetailSearchSelector/base.ts does not touch searchTerm — the input is genuinely controlled via textInputOptions.value, so the clear comes solely from the component default above.

Alternative considered: flipping the component's default to false to match the old SelectionList. Rejected as riskier — other pages using SelectionListWithSections may rely on the current clear-on-select behavior, so a per-page opt-out is the safe, minimal fix.

Web-only report: the clear runs on all platforms (native delegates to the same component), so this fix resolves it everywhere; native may just mask it via keyboard/focus behavior. Worth a quick device check during QA.

Related issues

None found that are duplicates. Expensify/App#92803 (Enter key doesn't open Confirm page when adding members) touches the same invite flow but is a distinct bug.

---

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

[melvin-bot]

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

[melvin-bot]

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

[yuwenmemon]

@MelvinBot implement this

[MelvinBot]

🤖 Draft PR created: #97300

What it does: Passes shouldClearInputOnSelect={false} to the <SelectionListWithSections> in DynamicWorkspaceInvitePage.tsx so the typed search term is retained across selections, exactly as proposed. Migrating this page to SelectionListWithSections had flipped the default to true, which cleared the search on every selection.

Checks run locally: oxfmt, ESLint, typecheck, and the React Compiler compliance check all pass. There is no dedicated unit test for this page, so no test was added for the one-line prop change — please verify the flow manually and fill in the Tests / QA sections before marking the PR ready.

Please mark it as "Ready for review" when it is ready.

[mananjadhav]

The PR was deployd on staging. Waiting for the prod deploy.