[Due for payment 2026-09-23] Workspace - Bulk button remains checked after clearing search field

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.75-2
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/test-runs/72388031/folder/53678249/41237950/1726842114?sort=%2Bidentifier
Email or phone of affected tester (no customers): rogerjesusrosarioh+a78sd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Web
App Component: Workspace Settings

Action Performed:

1. Navigate to a workspace and add at least 16 members, can be random
2. On the manage members list, search for a query that returns at least 2 accounts from the members list
3. Click on the bulk select to select all
4. Clear the search field

Expected Result:

Bulk select checkbox should be cleared/unchecked after clearing the search field.

Actual Result:

Bulk select checkbox still checked after clearing the search field.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256399_1789069479283.ExpensifyBulkStillChecked.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7256399

Issue Owner

Current Issue Owner: @linhvovan29546

[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/ea8f03d52945d5255498014a117a3bb7840888a0c0d3d0e1457db221f1830e78

[MelvinBot]

Proposal

What is the root cause of that problem?

The Members table is the only table in the app that opts out of clearing its selection when the search text changes.

src/components/Tables/WorkspaceMembersTable/index.tsx:352 passes shouldPreserveSelectionOnSearch, which short-circuits the shared clear-on-search effect in src/components/Table/middlewares/selection.ts:139-149. So the two logins you selected while the search was active stay in selectedEmployees after you clear the field.

The header checkbox is then derived from the currently visible rows in src/components/Table/TableHeader.tsx:108-120. With 2 of 16 rows selected it computes isSelectionIndeterminate rather than isChecked — but src/components/SelectionButton.tsx:202-215 applies the identical filled-green checkedContainer style to both states, changing only the inner icon (minus instead of a checkmark). That is why it reads as "still checked".

There is a more serious defect behind the cosmetic one: selectedEmployees is never pruned to the visible row set (WorkspaceMembersPage.tsx:125), so the "N selected" button (line 747) and its bulk actions — Remove members, Change role — keep operating on members the admin can no longer see. An admin who searches, selects, clears, then searches again can remove members they never looked at.

Regression source and supporting evidence

Introduced by #93877 ("Update table pages to scroll full page", merged 2026-08-24), in commit 96e9183cc "Preserve member selection during search". That commit replaced the single combined effect:

// before
useEffect(() => clearSelection(), [currentFilters, activeSearchString, clearSelection]);

with two separate effects — filters always clear, search clears only when the new shouldPreserveSelectionOnSearch flag is unset — and set the flag on WorkspaceMembersTable in the same commit. Before that PR, clearing the search dropped the selection on the Members page too, which matches the Expected Result in this report. The issue was filed on v9.4.75-2, 18 days after that merge.

Scope check: a repo-wide grep for shouldPreserveSelectionOnSearch returns only the type definition (types.ts:196), the middleware, Table.tsx, and this one call site. Every other searchable multi-select table (Categories, Tags, Taxes, Distance Rates, Per Diem, Company Cards) still clears on search, so this is page-specific, not systemic.

Why "at least 16 members" is not actually a threshold: nothing in the current Table gates the search input on a row count — TableFilterBar renders it whenever there is any data. CONST.STANDARD_LIST_ITEM_LIMIT (12) is not referenced by this page. The 16 in the test case just makes the filtering visible; the bug reproduces with any list where a query matches a strict subset.

Alternative explanations ruled out:

• Header compares against the full list instead of the filtered list — no. It is a per-row AND over the visible rows, never a selected.length === total comparison.
• Select-all selects hidden rows — no. selection.ts:159-172 only ever selects the visible selectableKeys.
• Stale selection-mode state on narrow layout — not applicable; this was reported on Windows Chrome, a wide layout, where isSelectionCheckboxVisible === selectionEnabled and the state loop runs normally.

Not verified in a live browser. The test session in this run went unresponsive before the Members page could be reached, so this rests on code evidence plus the regression diff, not a reproduction.

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

Remove the shouldPreserveSelectionOnSearch prop from the Table in WorkspaceMembersTable. That is one line, restores the behavior this test case expects, and puts the Members page back in line with every other table in the app.

Two things the reviewer should weigh before taking that:

1. That flag is deliberate and documented, added specifically for this page. Dropping it reverts an intentional decision, so someone should confirm that "clearing the search resets the bulk selection" is the wanted product behavior. Nothing else depends on it — the only test covering the flag (tests/ui/TableTest.tsx:3084-3101) declares its own local flag, so it keeps passing either way.
2. If preserving the selection across searches is wanted, then the fix is not in the checkbox. The selection must be scoped to the visible rows wherever it is consumed, so that "N selected" and the bulk actions cannot reach hidden members. Fixing only the checkbox visual would close this report while leaving the remove-invisible-members path open.

I'd take option 1: it is smaller, it matches the convention, and it removes the hidden-member risk rather than managing it.

Alternative solutions explored

• Prune preserved keys to the visible set when the query clears. Keeps cross-search accumulation while fixing the count. But there is no existing hook for this, and it produces a confusing middle state where selections silently vanish as you type.
• Change the indeterminate visual so it no longer reads as checked. Purely cosmetic. Indeterminate is arguably the correct signal for "some rows selected", so the real disagreement is about whether the selection should survive at all. This does not address the bulk-action risk.
• Use useFilteredSelection (src/hooks/useFilteredSelection.ts), as Distance Rates and Per Diem do. It prunes against the full option set rather than the searched set, so it would not fix this.

Related issues

My scan of open issues found no duplicate. Expensify/App#90539 (shift+click range selection in multi-select lists) touches the same Table selection engine but is a separate feature request.

---

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

---

view run · no recording available

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[ceosss]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Workspace Members page, an admin searches for members, ticks the bulk-select header checkbox, then clears the search field. The header checkbox still reads as checked even though only the 2 previously matched members out of 16 are selected.

What is the root cause of that problem?

src/components/Tables/WorkspaceMembersTable/index.tsx:352 passes shouldPreserveSelectionOnSearch, which short-circuits the clear-on-search effect in src/components/Table/middlewares/selection.ts:139-149. The 2 logins selected under the query stay in selectedEmployees after the field is cleared.

The header checkbox is derived from the visible rows in src/components/Table/TableHeader.tsx:108-120. With 2 of 16 rows selected it computes isSelectionIndeterminate, not isChecked. src/components/SelectionButton.tsx:202-215 applies the same filled checkedContainer style to both states and changes only the inner icon, so indeterminate reads as checked.

Underneath the cosmetic report there is a correctness defect. selectedEmployees is plain page state at src/pages/workspace/WorkspaceMembersPage.tsx:125 with no relationship to the visible row set. Five consumers read it raw: the confirmation prompt (:166-193), removeUsers (:234-267), changeUserRole (:524-531), getBulkActionsButtonOptions (:535-605) and the "N selected" button (:747). An admin who searches, selects, clears, then searches again can remove or re-role members they cannot see on screen.

The important part is why that flag exists, because it decides the fix. It was not part of the scope of #93877 ("Update table pages to scroll full page", issue #92930). It was added in a mid-review follow-up commit, 96e9183cc, answering a reviewer report that a selection was being destroyed by a search that matched nothing. The PR author described the result as member selections surviving "search -> no results -> Clear, with the same rows still checked", and tests/ui/TableTest.tsx:3084-3101 pins exactly that sequence.

So the intent was narrow and legitimate: do not throw away a selection because a query happened to match nothing. The flag implements something much wider, preserving the selection across every search, including one that matches a strict subset. That over-generalisation is the root cause. Both the no-results behaviour and this report are correct requirements; they are distinguishable by whether a search is currently active, which Table already computes as hasActiveSearchString in src/components/Table/middlewares/searching.ts:67.

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

Unlike a straight removal of the shouldPreserveSelectionOnSearch prop, this keeps the flag and narrows it to the case it was written for, so the no-results behaviour added in 96e9183cc survives; it also closes the hidden-member path in one shared place rather than leaving it open.

In src/components/Table/middlewares/selection.ts, change the opted-in branch of the search effect (:139-149) from "never clear" to "preserve while a search is active, reconcile when it ends". When shouldPreserveSelectionOnSearch is set and the search string becomes empty, intersect selectedKeys with the keys that are actually present, instead of returning early:

const visibleKeys = new Set(data.map((item) => item.keyForList));
onRowSelectionChange?.(selectedKeys.filter((key) => visibleKeys.has(key)));

This belongs in the middleware rather than the page. useSelection is already handed the post-search rows (src/components/Table/Table.tsx:297-305 passes sortedData, which the search middleware has already filtered), so the visible key set is in scope. Every consumer of the selection routes through onRowSelectionChange, so one guard fixes the header checkbox and all five bulk-action consumers on the Members page at once, with no change to WorkspaceMembersPage.tsx and no per-call-site pruning.

The behaviour this produces:

• Search matches a subset, select, clear the field: selection reduces to rows still present, the header checkbox returns to unchecked, and the bulk actions can no longer reach hidden members. This is the reported case.
• Search matches nothing, clear the field: no rows were filtered away by a real match, the preserved keys are all still in the data, so they survive. This is the case 96e9183cc added and TableTest.tsx:3084-3101 covers, and it keeps passing unchanged.
• Filters are untouched. selection.ts:139 still clears on any filter change.
• No other table is affected. shouldPreserveSelectionOnSearch has exactly one call site outside the type definition, the middleware and Table.tsx.

Optional and separable, not required to close this issue: SelectionButton.tsx:202-215 paints indeterminate and checked identically, differing only by a minus versus a checkmark glyph. That is app-wide, affects every multi-select table, and is arguably wrong on its own, since an indeterminate control should not be visually indistinguishable from a fully checked one. The accessibility layer already reports these states correctly (aria-checked="mixed" at :186-188), so only the visual is at odds. I would raise it separately rather than fold a design change into this fix, and this proposal closes the reported issue without it.

What specific scenarios should we cover in automated tests?

In tests/ui/TableTest.tsx, against the existing ControlledSelectableTable harness which already supports showSearch and shouldPreserveSelectionOnSearch:

1. With preservation on, search a query matching a strict subset, select all via the header checkbox, clear the search: selected keys reduce to the matched subset only, and no key outside it appears.
2. With preservation on, the existing no-results case at :3084-3101 still holds, so keys survive a search that matches nothing and the subsequent clear.
3. With preservation on, select rows, search a subset, clear: keys selected before the search that fall outside the matched set are dropped, confirming the count cannot exceed the visible rows.
4. With preservation off, the existing clear-on-search case still holds.
5. In tests/ui/TableTest.tsx, after case 1 the header checkbox is neither checked nor indeterminate, asserted through the accessibility state rather than the style.
6. In tests/ui/WorkspaceMembersTest.tsx, search, select, clear, then open the bulk actions menu: the "N selected" count matches the number of visible selected rows.

What alternative solutions did you explore? (Optional)

Removing the shouldPreserveSelectionOnSearch prop. One line, and it does resolve the reported symptom, but it re-breaks the no-results case that 96e9183cc was written to fix after review feedback. TableTest.tsx:3084-3101 would not catch that regression, since it declares its own local flag rather than reading the Members table's, so the suite passes while the behaviour is lost.

Pruning inside WorkspaceMembersPage.tsx. The page does not observe the table's search string; onSearchStringChange is wired only for RoomMembersTable and DynamicRoomMembersPage.tsx:379. Adding that wiring to push the query up to the page duplicates state the table already owns, and still leaves every other opted-in table to fix separately.

useFilteredSelection (src/hooks/useFilteredSelection.ts). I checked all five call sites. It filters selected keys against an options record, and each caller passes an eligibility predicate, pendingAction for distance rates (PolicyDistanceRatesPage.tsx:148) and mere existence for per diem (WorkspacePerDiemPage.tsx:141). It has no access to the search string, so it prunes deleted or ineligible rows, never rows hidden by a query. It cannot express this fix.

Fixing only the checkbox visual. This closes the report as written and leaves the bulk actions still able to act on members the admin cannot see.

[linhvovan29546]

@MelvinBot Before I accept this, I want to flag a tradeoff in the proposed fix (removing shouldPreserveSelectionOnSearch from WorkspaceMembersTable).

That flag was added in commit 96e9183 (part of PR #93877), and its only test coverage (tests/ui/TableTest.tsx, "should preserve opted-in selection through a no-results search and clear") is specifically about a search that matches zero rows — not a search that matches a subset. The PR author's own description of that fix was: "Member selections now survive search → no results → Clear, with the same rows still checked," in response to a reviewer report that the app "behaves weirdly when selecting, focusing on the input, and scrolling."

If we remove the flag outright, we restore the original combined clear-on-any-search-change effect — which also reintroduces that no-results regression: an admin who selects members, then types a search that happens to match nothing, would have their selection silently wiped before they've cleared anything.

Can you revise the proposal so the fix preserves selection while a search is actively narrowing results (including a no-results search), but reconciles the selection down to the visible rows only when the search is cleared? A simple removal or an intersection against the current post-search data won't do this correctly, since by the time the search-cleared effect fires, data has already reverted to the full unfiltered list — the reconciliation needs to be based on what was visible immediately before the clear, not what's visible after it.

[ceosss]

You are right, and the objection lands on my proposal too. Thank you for catching it.

My change section says to intersect against the rows present when the search string becomes empty. That does not work, for exactly the reason you give. The effect is keyed on activeSearchString (selection.ts:142-149), and Table.tsx recomputes searchedData from that same value in the same render, so by the time the effect runs the data has already reverted to the full unfiltered list. The intersection matches everything and removes nothing. My snippet is a no-op in the reported case.

The correction is to reconcile against what was visible immediately before the clear, not after it. usePrevious is already imported in this file (:5) and already used a few lines above for wasSelectionModeEnabled (:130), so the shape fits what is there:

const previousVisibleKeys = usePrevious(selectableKeys);
const hadActiveSearch = usePrevious(!!activeSearchString);

In the opted-in branch, act only on the transition from a search being active to the string being empty, and intersect the preserved keys with previousVisibleKeys. While a search is active, including one that matches nothing, nothing is cleared, so the 96e9183cc behaviour and its test at TableTest.tsx:3084-3101 are untouched.

That gives the three cases:

• Search narrows to a subset, select, clear: the previous visible set is the narrowed rows, so the selection reduces to those. The header checkbox returns to unchecked and the bulk actions can no longer reach hidden members.
• Search matches nothing, clear: the previous visible set is empty, so there is nothing to reconcile against and the preserved keys survive, which is the case the flag was added for.
• Filters unchanged: :139 still clears on any filter change.

One thing worth deciding explicitly, since it is a product call rather than a code one. In the no-results case the selection survives, which is intended. In the subset case it shrinks. Both are defensible, but they are different answers to "what does clearing a search mean", so it is worth stating which one you want before this is implemented.

[MelvinBot]

Revised Proposal

You're right about the mechanism, and I'm withdrawing the "just remove the prop" recommendation. But the rule you described — intersect the preserved keys with the rows visible immediately before the clear — is a no-op for the exact repro in this report, so it needs one more piece. Details below.

Please re-state the problem that we are trying to solve in this issue.

Two requirements that the current code can only satisfy one of at a time:

1. An admin searches, bulk-selects the matched rows, clears the search → the header checkbox must return to unchecked, and the bulk actions must not reach members who are no longer on screen. (This report.)
2. An admin selects members, types a query that matches nothing, clears it → the selection must survive. (Added in 96e9183cc, pinned by tests/ui/TableTest.tsx:3085-3101.)

What is the root cause of that problem?

shouldPreserveSelectionOnSearch turns the search effect into all-or-nothing: selection.ts:143-149 either clears on every search change or never clears. Requirement 2 is why the flag exists; requirement 1 is what it broke.

Your objection to my earlier fix is correct and it applies to ceosss's intersection snippet too. useSelection receives sortedData (Table.tsx:310-326), which is recomputed from activeSearchString in the same render that clears it. So when the effect fires, data is already the full 16-row list and selectableKeys (selection.ts:86) contains every member. Intersecting against it removes nothing.

The part worth flagging back: fixing that timing bug alone still doesn't close this report. In the repro the admin selects only rows the query matched, so selectedKeys is already a subset of the pre-clear visible set. {2 matched rows} ∩ {2 matched rows} = {2 matched rows} — the selection survives, the header stays indeterminate, and SelectionButton.tsx:202-215 paints indeterminate with the same filled style as checked, which is the "still checked" symptom. A correct intersection fixes the hidden-member defect (selections made before a search that hides them) but not the reported one. The reconciliation has to also drop keys chosen inside the narrowed view.

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

All in src/components/Table/middlewares/selection.ts. No change to WorkspaceMembersTable, WorkspaceMembersPage, or any other table.

1. Snapshot what a query leaves visible, while that query is still applied. This is the missing record you identified:

const hasActiveSearchString = activeSearchString.trim().length > 0;
const hadActiveSearchString = usePrevious(hasActiveSearchString);

// `data` reverts to the full list in the same render that clears the query, so this snapshot is the
// only record of what the admin could actually see when they made the selection.
const visibleKeysDuringSearch = useRef<string[]>([]);
useEffect(() => {
    if (!hasActiveSearchString) {
        return;
    }
    visibleKeysDuringSearch.current = selectableKeys;
    // selectableKeys is derived from the searched data, so activeSearchString is the trigger we key on
    // eslint-disable-next-line react-hooks/exhaustive-deps
}, [activeSearchString, hasActiveSearchString]);

usePrevious returns its render-time value, so hadActiveSearchString is true on exactly the clearing render regardless of effect ordering — and the snapshot effect short-circuits on that render, leaving the ref holding the last searched set.

2. Leave the existing effect alone for tables that don't opt in, and add a second one for those that do:

useEffect(() => {
    // Only act on the search -> cleared transition. While any query is applied, including one that
    // matches nothing, the selection is left untouched.
    if (!shouldPreserveSelectionOnSearch || !hadActiveSearchString || hasActiveSearchString) {
        return;
    }

    // A query that matched nothing never hid a row, so there is nothing to reconcile against and the
    // selection stands. This is the case 96e9183cc was written for.
    if (visibleKeysDuringSearch.current.length === 0) {
        return;
    }

    // The query did narrow the list, so the selection only ever had meaning inside that narrowed view.
    clearSelection();
}, [hasActiveSearchString, hadActiveSearchString, clearSelection, shouldPreserveSelectionOnSearch]);

Resulting behaviour:

Sequence	Result
Search matches a subset → select all → clear	Selection dropped, header unchecked. This report.
Select rows → search matches nothing → clear	Selection intact. 96e9183cc + its test, unchanged.
Select rows → search hides some of them → clear	Selection dropped, so bulk actions can't reach hidden members.
Any filter change	Unchanged — selection.ts:140 still clears.
Any table without the flag	Unchanged — the flag has one call site, WorkspaceMembersTable/index.tsx:352.

One decision for you, because it's a product call, not a code one. Step 2 clears rather than intersects when the query narrowed the list. That is the only rule I found that satisfies both requirements, and it matches the issue's Expected Result and every other table in the app. If you'd rather the selection shrink instead of vanish, see the "search as a scope" alternative below — it's a real option, just more state.

Known trade-off of the zero-match carve-out: typing a (5 matches) then ab (0 matches) then clearing preserves the selection, because the last query matched nothing. Rare, and it's the direction 96e9183cc chose.

What specific scenarios should we cover in automated tests?

In tests/ui/TableTest.tsx, using the existing ControlledSelectableTable harness, which already takes showSearch and shouldPreserveSelectionOnSearch:

1. Preservation on: search a strict subset → press Select All → clear. Selected keys are empty. This is the guard for the reported bug, and it fails against the intersection-only fix.
2. Preservation on: select rows → search a subset that excludes some of them → clear. Selected keys are empty, so no hidden key can survive.
3. Preservation on: the existing no-results case at 3085-3101 still passes unmodified.
4. Preservation on: keys stay selected while the query is applied, asserted before the clear, so nobody later "simplifies" this into clear-on-any-search-change.
5. Preservation off: the existing case at 3103-3111 still passes.
6. After case 1, the header checkbox is neither checked nor indeterminate, asserted via accessibility state (aria-checked) rather than style.

What alternative solutions did you explore?

Four alternatives, and why I didn't take them

• Intersect with the pre-clear visible set instead of clearing. Literally what you asked for, and it does fix the hidden-member path — but as shown above it leaves the reported repro unchanged, because the selection is already a subset of what was visible. Necessary, not sufficient.
• Search as a scope. Snapshot the selection when a query starts, and on clear keep (keys selected before the search) ∩ (keys visible before the clear), discarding anything chosen inside the query. Satisfies all three rows of the table above and is arguably the nicest model. It needs a second ref plus a search-start transition, and it introduces a rule users have to learn ("selections made inside a search don't outlive it"). Happy to write this up instead if you prefer shrink-over-clear.
• Removing the prop (my earlier recommendation). Withdrawn for the reason you gave: it re-breaks the no-results case, and TableTest.tsx:3085 wouldn't catch it because the harness declares its own local flag rather than reading the Members table's.
• Pruning in WorkspaceMembersPage. The page never sees the table's search string — onSearchStringChange is only wired for RoomMembersTable. Pushing the query up duplicates state the table owns and leaves every future opt-in table to fix separately.
• Changing only the indeterminate visual. SelectionButton.tsx:202-215 rendering indeterminate identically to checked is a genuine app-wide issue (the a11y layer already reports mixed correctly at :186-188), but it's a separate design change and it would leave the bulk actions still able to act on members the admin can't see.

Not verified in a live browser — this is code-level reasoning against f777fab, plus the 96e9183cc diff.

---

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

---

view run · no recording available

[linhvovan29546]

@MelvinBot I'm accepting the original "remove shouldPreserveSelectionOnSearch" approach instead of the snapshot-based fix. Reasoning:

• It brings Members in line with every other searchable table in the app (Categories, Tags, Taxes, Distance Rates, Per Diem, Company Cards), all of which already clear selection on any search-string change with no special-casing.
• It's the minimal, lowest-risk diff one line removed, no new refs/effects to maintain in selection.ts.

🎀 👀 🎀 C+ reviewed