[$250] Spend-Hybrid-Tap on checkbox does not select the group

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.27-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #95028
Email or phone of affected tester (no customers): duytestnguyen+250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Pixel 7a/ Android 16
App Component: Search

Action Performed:

Preconditions:

• Account that has many expenses

1. Open Hybrid app
2. Tap on Search icon on top right
3. Enter the query: "type:expense group-by:category"
4. Search the query
5. Trigger selection mode
6. Tap on checkbox

Expected Result:

User can select the group by tapping on the checkbox

Actual Result:

Unable to select the group. If tap on the expend arrow, group is selected

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7200401_1783309719134.Tap_On_Box_Does_Not_Select_The_Report.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7200401

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074060257650630208
• Upwork Job ID: 2074060257650630208
• Last Price Increase: 2026-07-06

[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/1a5936f6055bd5f73533a6b1c283e9de848383f184e359785d8ad431e4ae805e

[MelvinBot]

Proposal

⚠️ Medium confidence — the where and the regression source are solid; the exact native touch mechanism should be confirmed on-device (see note at the end).

What is the root cause of that problem?

This is a regression from #95028, which introduced the new grouped‑expense search view. On narrow layouts (Android/iOS App) a category group renders through TransactionGroupListItem → BaseListItemHeader (the wide‑web split into a standalone GroupHeader row is skipped — see shouldSplit).

In that narrow header the select checkbox is a nested pressable (BaseListItemHeader.tsx:150-160), but it lives inside the outer group PressableWithFeedback whose onPress only toggles expand/collapse for a category group — it never selects (TransactionGroupListItem.tsx:302-309, wired at :545-548). So the checkbox tap does not reach its selection handler handleSelectionButtonPress → onSelectionButtonPress (toggle) — the group is never selected.

On wide web the same group is split into its own top‑level GroupHeader list row, so the checkbox isn't shadowed by an expand pressable and selection works — which is why the bug is native/narrow‑only.

Handler wiring (for reference)

• Checkbox → onCheckboxPress = handleSelectionButtonPress → onSelectionButtonPress (SELECT).
• Expand arrow → onDownArrowClick = onExpandIconPress → handleToggle (EXPAND).
• Both, plus the whole row, are nested inside the outer expand pressable, so the touch responder resolves to expand rather than the checkbox's select. (The reporter's "tap the arrow → group is selected" most likely describes the group expanding; the actionable defect is that the checkbox does not select.)

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

Make the group checkbox reliably toggle selection on native instead of being shadowed by the outer expand pressable. Concretely, on narrow layout mirror the wide‑web behavior so the checkbox press isn't nested inside a pressable whose onPress expands — e.g. give the checkbox region its own press area that calls handleSelectionButtonPress and stops propagation to the outer row, or make the outer onPress route to selection (not expand) when a tap originates on the checkbox in selection mode. Verify parity against the working GroupHeader path.

What alternative solutions did you explore? (Optional)

Note: the shared Checkbox/SelectionButton guard (SelectionButton.tsx:155-161) is used by every checkbox in the app and works on mobile elsewhere, so it is not the cause — the problem is specific to this grouped narrow‑layout nesting.

Verification needed: this should be reproduced/confirmed on an Android or iOS build (the /agent-device skill) to pin down whether it's a nested touch‑responder conflict vs. a hit‑area overlap, before finalizing the exact fix.

Related issues

A quick scan didn't surface a clear duplicate of this specific grouped‑checkbox defect.

---

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

[kitvasyl]

Proposal

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

On Android and iOS Hybrid, tapping the checkbox of a collapsed type:expense group-by:category group in selection mode does not select its expenses, although tapping the expand arrow does.

What is the root cause of that problem?

On native layouts, ExpenseGroupedSearchView renders each group through TransactionGroupListItem. Category group rows initially contain transactions: [] plus a transactionsQueryJSON; their child transactions are populated only after the corresponding snapshot is fetched.

In TransactionGroupListItem, a not-yet-loaded snapshot also produces transactions = []. The component then sets isEmpty = true and, critically, isDisabledOrEmpty = isEmpty || isDisabled, which disables the group checkbox. This incorrectly treats “children not fetched yet” as “genuinely empty.”

The expand arrow follows a different path: onExpandIconPress() calls onPress(), which records the group-key selection and calls refreshTransactions(). Once the snapshot arrives, the existing selection reconciliation propagates that temporary group selection to every child transaction. That explains why the arrow works while the disabled checkbox does nothing.

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

In TransactionGroupListItem, distinguish a loadable pending snapshot from a loaded empty result, for example with an isTransactionsSnapshotPending boolean based on a present transactionsQueryJSON and missing transactionsSnapshot.data. Change isDisabledOrEmpty so the checkbox remains enabled while that snapshot is pending, but remains disabled for deleted rows, groups without a loadable query, and loaded empty results.

Then update handleSelectionButtonPress() to preserve its existing selection callback and additionally call refreshTransactions() when the child snapshot is pending. This reuses the established arrow behavior without expanding the row: toggle() immediately stores the group-key selection, and the existing reconciliation replaces it with concrete child selections after loading. No selection-provider or global search changes are needed.

Add focused tests in TransactionGroupListItemTest.tsx covering an unfetched category group: its checkbox is enabled, pressing it invokes selection and requests its child query while keeping the row collapsed, and a loaded empty snapshot remains disabled. Also verify that resolving the snapshot selects all child transaction keys and that a second checkbox press deselects them. Manually verify the collapsed and previously expanded/cached cases on Android and iOS.

What alternative solutions did you explore? (Optional)

Simply removing the empty-state disable gate is incomplete because the checkbox would store only the temporary group key without fetching the child transaction IDs needed by bulk actions. Preloading every group in useSearchSnapshot would solve that, but would issue unnecessary requests for groups the user never selects or expands; the local select-and-fetch path is smaller and matches the existing expand-arrow transition.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 09:20:21 UTC.

Proposal

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

In a grouped expense Search (e.g. type:expense group-by:category), on native (iOS App / Android App) when selection mode is on, tapping a group row's checkbox does not select the group. The only way to select is to tap the expand arrow. On wide web the same checkbox works, so this is specific to the narrow/native rendering path.

What is the root cause of that problem?

Grouped-expense rows render through two different components depending on layout. On wide web (shouldSplit) each group renders via GroupHeader; everywhere else — including all of native and narrow web — each group renders via TransactionGroupListItem. Both draw the same header checkbox through BaseListItemHeader, and that Checkbox is wired to be disabled whenever the header's isDisabled prop is truthy:

App/src/components/Search/SearchList/ListItem/BaseListItemHeader.tsx

Lines 151 to 155 in fb8771e

	<Checkbox
	onPress={() => onCheckboxPress?.(item as unknown as TItem)}
	isChecked={isSelectAllChecked}
	isIndeterminate={isIndeterminate}
	disabled={!!isDisabled || item.isDisabledCheckbox}

The header's isDisabled comes from isDisabledOrEmpty in each row component. The problem is that the two components compute "empty" differently. For a category/merchant/tag/date group, the group item carries transactions: [] in the main snapshot plus a transactionsQueryJSON — the real child transactions live in a separate sub-snapshot that is only fetched when the group is expanded (see getCategorySections, which sets transactions: [] alongside transactionsQueryJSON). So a freshly-searched, collapsed group always has an empty local transactions array. In TransactionGroupListItem, isEmpty is derived purely from that empty local array, which makes isDisabledOrEmpty true and disables the checkbox:

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 181 to 185 in fb8771e

	const isEmpty = transactions.length === 0;
	const isEmptyReportSelected = isEmpty && item?.keyForList && selectedTransactions[item.keyForList]?.isSelected;
	const isSelectAllChecked = isEmptyReportSelected || (selectedItemsLength === transactionsWithoutPendingDelete.length && transactionsWithoutPendingDelete.length > 0);

const isDisabledOrEmpty = isEmpty || isDisabled; (line 190) then flows into isDisabled={isDisabledOrEmpty} on every header variant, and BaseListItemHeader passes that straight to Checkbox's disabled. A disabled Checkbox never fires onPress, so onCheckboxPress → toggle is never reached and nothing is selected. GroupHeader (the wide-web path) does NOT hit this because its isEmpty explicitly excludes groups that have a sub-query, so its checkbox stays enabled:

App/src/components/Search/SearchList/ListItem/GroupHeader.tsx

Lines 174 to 177 in fb8771e

	const hasSnapshotTransactions = !isExpenseReportType && !!snapshotData && Object.keys(snapshotData).some((key) => key.startsWith(ONYXKEYS.COLLECTION.TRANSACTION));
	const isEmpty = groupItem.transactions.length === 0 && !hasSnapshotTransactions && !groupItem.transactionsQueryJSON;
	const isDisabled = item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
	const isDisabledOrEmpty = isEmpty || isDisabled;

This single wrong flag also explains the "tap the expand arrow and it selects" workaround: onExpandIconPress branches on the same isEmpty (if (isEmpty && !shouldDisplayEmptyView) { onPress(); }), so on a collapsed category group the arrow is misrouted into the empty-report select path instead of just expanding. One misclassification (isEmpty === true for a group that actually has transactions behind a sub-query) produces both halves of the report. This is a latent narrow-path bug, not something #95028 changed — #95028 moved grouped rendering into ExpenseGroupedSearchView but still renders the unchanged TransactionGroupListItem, which is why it reproduces in production and was merely surfaced during that PR's regression pass.

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

Make TransactionGroupListItem's checkbox-disable computation match the already-correct logic in GroupHeader: a group with a transactionsQueryJSON (or with loaded snapshot transactions) has real, selectable transactions and must not be treated as empty. We only need to decouple the disable flag from the display-only isEmpty, leaving isEmpty itself untouched so that isEmptyReportSelected (checkbox checked-state), shouldDisplayEmptyView, and the expanded-view rendering keep working. Concretely, in TransactionGroupListItem.tsx replace line 190 with the GroupHeader-style check:

const hasSnapshotTransactions =
    !isExpenseReportType && !!transactionsSnapshot?.data && Object.keys(transactionsSnapshot.data).some((key) => key.startsWith(ONYXKEYS.COLLECTION.TRANSACTION));
const isDisabledOrEmpty = (isEmpty && !hasSnapshotTransactions && !groupItem.transactionsQueryJSON) || isDisabled;

Everything referenced here is already in scope in this component (transactionsSnapshot, isExpenseReportType, groupItem, ONYXKEYS), so this is a minimal, local change. It's safe for the other callers: expense-report groups have no transactionsQueryJSON and !isExpenseReportType is false, so hasSnapshotTransactions is false and the expression collapses back to the old isEmpty || isDisabled — a genuinely empty expense report stays disabled exactly as today. For category/merchant/tag/date groups (which always carry a sub-query) the checkbox becomes enabled, so tapping it reaches toggle and selects the group. Because we don't touch isEmpty, the checked-state math and empty-report toggle path are unchanged.

What alternative solutions did you explore? (Optional)

Redefining the shared isEmpty itself to include !transactionsQueryJSON would also enable the checkbox, but it would break the checkbox's checked-state: isEmptyReportSelected relies on isEmpty being true for a collapsed group so the box shows as checked after selecting it by group key, so a global change would leave the group selected but visually unchecked. Scoping the change to only the disable flag avoids that regression.

What specific scenarios should we cover in automated tests to prevent this bug from occurring in the future?

We should add a test to tests/unit/Search/ExpenseGroupedSearchViewTest.tsx rendering a grouped-expense search (e.g. group-by:category) at a narrow/native layout with selection mode enabled and collapsed groups whose local transactions array is empty but which carry a transactionsQueryJSON, then assert the group header checkbox is not disabled and that pressing it dispatches toggle / adds the group to selectedTransactions. We should also cover the inverse: a truly empty expense-report group (no transactionsQueryJSON) still renders a disabled checkbox, guarding against re-enabling selection on genuinely empty rows.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 09:27:48 UTC.

Proposal

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

In Search, when you group results (for example type:expense group-by:category) and turn on selection mode, tapping a group's checkbox does nothing. The group can't be selected that way. Tapping the expand arrow does select the group, which is the opposite of what you'd expect. This happens on Android/iOS app and any narrow-width layout (mWeb, narrow desktop), but not on large-screen web.

What is the root cause of that problem?

The checkbox is disabled, so the tap is a no-op. It's not an event-propagation issue, the checkbox is wired correctly (onCheckboxPress → handleSelectionButtonPress), it just never gets the chance to fire.

In src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx, line 181 computes const isEmpty = transactions.length === 0; and line 190 computes const isDisabledOrEmpty = isEmpty || isDisabled;. That value flows into every group header (isDisabled={isDisabledOrEmpty}) and ends up on the checkbox's disabled prop.

The problem is that grouped searches like category, tag, merchant, member, card, and the date buckets are query-backed. SearchUIUtils builds these groups with transactions: [] plus a transactionsQueryJSON, and the children are lazy-loaded from a snapshot only when you expand the group. So while a group is collapsed, transactions.length === 0, which makes isEmpty true, which disables the checkbox. That's why every one of these group types is affected, not just category.

The arrow behaves oddly for the same reason. onExpandIconPress (line 323) does if (isEmpty && !shouldDisplayEmptyView) { onPress(); return; }, and for these groups onPress runs the selection handler and then expands, so the arrow both selects and expands.

Large-screen web renders these groups through a different component, GroupHeader.tsx, which already guards for this. Its isEmpty (line 175) is transactions.length === 0 && !hasSnapshotTransactions && !groupItem.transactionsQueryJSON, so a query-backed group is not treated as empty and its checkbox stays enabled. The narrow-screen TransactionGroupListItem never got that same guard, which is why the two paths behave differently.

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

Port the guard that GroupHeader already uses. Change line 190 in TransactionGroupListItem.tsx so a query-backed group isn't counted as empty for the disable decision:

const isDisabledOrEmpty = (isEmpty && !groupItem.transactionsQueryJSON) || isDisabled;

isDisabledOrEmpty only feeds the header's isDisabled, which only feeds the checkbox disabled, so the blast radius is the checkbox. isEmpty itself stays as-is, so isEmptyReportSelected (line 183) keeps reflecting the group-key selection and the checkbox checks/unchecks correctly. shouldDisplayEmptyView and the expanded loading UI aren't touched.

I'd also add the missing test coverage in tests/unit/TransactionGroupListItemTest.tsx: render a collapsed category group with transactions: [] and a transactionsQueryJSON, assert the checkbox is not disabled, and assert that pressing it fires onSelectionButtonPress/toggle and flips the select-all state. That's the exact path that shipped broken.

What alternative solutions did you explore? (Optional)

The fuller alignment is to mirror GroupHeader more closely by also folding !groupItem.transactionsQueryJSON into isEmpty at line 181 and retargeting isEmptyReportSelected at line 183 to key off transactions.length === 0 directly. That version also fixes the arrow selecting the group, since onExpandIconPress would then only expand. The tradeoff is a wider ripple: isEmpty also feeds the expanded loading header/padding, so it's a bigger surface to verify for a mostly cosmetic gain. I'd lead with the line 190 change since it's minimal and matches the proven precedent, and fold in the line 183 retarget only if we also want the arrow to stop selecting.

[ahmdshrif]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[samranahm]

Proposal

What is the root cause of that problem?

When a user performs a search with a group-by query (e.g., type:expense group-by:category), the useSearchTypeMenuSections hook generates typeMenuSections containing menuItems for the grouped results. These menuItems are then rendered in components like SearchTypeMenuWide. Each grouped item displays a checkbox for selection.

The root cause is that the onPress handler specifically associated with the checkbox component within a grouped search result item is not correctly triggering the group selection action. While tapping the expand arrow (or the main row area) correctly selects the entire group, the checkbox's onPress either does not exist, is overridden, or calls a selection function that fails to identify and select the parent group. This leads to a discrepancy where the visual checkbox interaction does not match the expected selection behavior for grouped items.

• useSearchTypeMenuSections hook, which calls createTypeMenuSections to generate typeMenuSections:
  

  App/src/hooks/useSearchTypeMenuSections.ts

  Lines 130 to 142 in fb8771e

  	],
  	);
  	const activeItemIndex = useMemo(() => {
  	const isSavedSearchActive = hash !== undefined && !!savedSearches && Object.keys(savedSearches).some((key) => Number(key) === hash);
  	if (isSavedSearchActive) {
  	return -1;
  	}
  	let index = 0;
  	for (const section of typeMenuSections) {
  	const found = section.menuItems.findIndex((item) => {

• SearchTypeMenuWide component, which renders typeMenuSections and uses selection actions:
  

  App/src/pages/Search/SearchTypeMenuWide.tsx

  Lines 128 to 207 in fb8771e

  	function SearchTypeMenuWide({queryJSON}: SearchTypeMenuProps) {
  	const {hash, similarSearchHash, sortBy, sortOrder, type} = queryJSON ?? {};
  	const styles = useThemeStyles();
  	const {isOffline} = useNetwork();
  	const {singleExecution} = useSingleExecution();
  	const {clearSelectedTransactions} = useSearchSelectionActions();
  	const {typeMenuSections, activeItemIndex} = useSearchTypeMenuSections({hash, similarSearchHash, sortBy, sortOrder, type});
  	const {isVisuallyCollapsed} = useSearchSidebarCollapse();
  	const [isSearchDataLoaded, isSearchDataLoadedResult] = useOnyx(ONYXKEYS.IS_SEARCH_PAGE_DATA_LOADED);
  	// Intentionally left enabled (no focus freeze): the wide menu renders in the search navigator's ExtraContent
  	// slot, where useIsFocused() does not track visibility, so freezing on it would be unreliable.
  	const {counts: reportCounts} = useTodoCounts();
  	const route = useRoute();
  	const scrollViewRef = useRef<RNScrollView>(null);
  	const {saveScrollOffset, getScrollOffset} = useContext(ScrollOffsetContext);
  	const onScroll = (e: NativeSyntheticEvent<NativeScrollEvent>) => {
  	// If the layout measurement is 0, it means the flash list is not displayed but the onScroll may be triggered with offset value 0.
  	// We should ignore this case.
  	if (e.nativeEvent.layoutMeasurement.height === 0) {
  	return;
  	}
  	saveScrollOffset(route, e.nativeEvent.contentOffset.y);
  	};
  	const handleTypeMenuItemPress = singleExecution((searchQuery: string) => {
  	clearSelectedTransactions();
  	setSearchContext(false);
  	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: searchQuery}));
  	});
  	useLayoutEffect(() => {
  	const scrollOffset = getScrollOffset(route);
  	if (!scrollOffset || !scrollViewRef.current) {
  	return;
  	}
  	scrollViewRef.current.scrollTo({y: scrollOffset, animated: false});
  	}, [getScrollOffset, route]);
  	const sectionStartIndices = [0];
  	for (const section of typeMenuSections) {
  	sectionStartIndices.push((sectionStartIndices.at(-1) ?? 0) + section.menuItems.length);
  	}
  	const expenseReportsSection = typeMenuSections.find((section) => section.translationPath === 'search.tabs.expenseReports');
  	const nonExpenseReportsSections = typeMenuSections.filter((section) => section.translationPath !== 'search.tabs.expenseReports');
  	const areSuggestedSearchesLoading = !isOffline && !isSearchDataLoaded && !isLoadingOnyxValue(isSearchDataLoadedResult);
  	const [collapsedSectionCount, setCollapsedSectionCount] = useState(0);
  	const areAllSectionsExpanded = collapsedSectionCount === 0;
  	const updateCollapsedCount = (isCollapsed: boolean) => {
  	setCollapsedSectionCount((prevCollapsedCount) => prevCollapsedCount + (isCollapsed ? 1 : -1));
  	};
  	return (
  	<ScrollView
  	onScroll={onScroll}
  	ref={scrollViewRef}
  	showsVerticalScrollIndicator={false}
  	>
  	<View style={[styles.pb4, styles.mh3, styles.gap4]}>
  	{!!expenseReportsSection && (
  	<Section
  	section={expenseReportsSection}
  	onItemPress={handleTypeMenuItemPress}
  	onCollapsed={updateCollapsedCount}
  	hash={hash}
  	sectionStartIndex={0}
  	activeItemIndex={activeItemIndex}
  	reportCounts={reportCounts}
  	areAllSectionsExpanded={areAllSectionsExpanded}
  	/>
  	)}
  	{areSuggestedSearchesLoading ? (
  	<SuggestedSearchSkeleton
  	sectionCount={nonExpenseReportsSections.length || 2}
  	shouldHideLabels={isVisuallyCollapsed}

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

1. Ensure createTypeMenuSections (called within useSearchTypeMenuSections) provides a specific onPress handler for the checkbox of grouped menuItems.

   • The createTypeMenuSections function is responsible for generating the menuItems data, which includes properties and handlers for rendering. For grouped expenses, the menuItem object should be augmented with a distinct onPress callback specifically for its checkbox. This callback should be designed to toggle the selection of the entire group.
   • This involves identifying if a menuItem represents a grouped expense and, if so, defining an onPress handler that utilizes the group's reportID (or equivalent identifier) to interact with the selection logic provided by useSearchSelectionActions.
   • The useSearchTypeMenuSections hook calls createTypeMenuSections:
     

     App/src/hooks/useSearchTypeMenuSections.ts

     Lines 130 to 142 in fb8771e

     	],
     	);
     	const activeItemIndex = useMemo(() => {
     	const isSavedSearchActive = hash !== undefined && !!savedSearches && Object.keys(savedSearches).some((key) => Number(key) === hash);
     	if (isSavedSearchActive) {
     	return -1;
     	}
     	let index = 0;
     	for (const section of typeMenuSections) {
     	const found = section.menuItems.findIndex((item) => {

   • The SearchTypeMenuWide component uses useSearchSelectionActions which provides selection capabilities (e.g., toggleTransactionSelection):
     

     App/src/pages/Search/SearchTypeMenuWide.tsx

     Line 133 in fb8771e

     const {singleExecution} = useSingleExecution();

   // Conceptual change within createTypeMenuSections when constructing a grouped menuItem:
   if (menuItem.isGroupedExpense) {
       menuItem.checkboxOnPress = () => {
           // Call the appropriate selection action from useSearchSelectionActions
           // e.g., toggleTransactionSelection(menuItem.reportID, true);
           // The actual function name and parameters would depend on the implementation
           // of useSearchSelectionActions.
       };
   }

   This ensures that when the checkbox of a grouped item is tapped, it correctly triggers the selection of the entire group, aligning its behavior with the expand arrow.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[abbasifaizan70]

Proposal

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

When Search results are grouped (e.g. type:expense group-by:category), turning on selection mode and tapping a group's row checkbox does not select the group. Tapping the row's expand arrow instead does mark it as selected.

What is the root cause of that problem?

Grouped, non-report search results (category, tag, merchant, member, card, month, week, quarter, year, withdrawal ID) arrive from the backend with an always-empty transactions array — only the summary fields (count, total, currency, etc.) are populated up front. The real child transactions are fetched lazily, only after the row is expanded.

App/src/libs/SearchUIUtils.ts

Lines 3378 to 3402 in fec6b33

	function getCategorySections(data: OnyxTypes.SearchResults['data'], queryJSON: SearchQueryJSON | undefined): [TransactionCategoryGroupListItemType[], number, boolean] {
	const categorySections: Record<string, TransactionCategoryGroupListItemType> = {};
	for (const key in data) {
	if (isGroupEntry(key)) {
	const categoryGroup = data[key] as SearchCategoryGroup;
	const transactionsQueryJSON =
	queryJSON && categoryGroup.category !== undefined
	? buildSpecificGroupQuery(queryJSON, CONST.SEARCH.SYNTAX_FILTER_KEYS.CATEGORY, !categoryGroup.category ? CONST.SEARCH.CATEGORY_EMPTY_VALUE : categoryGroup.category)
	: undefined;
	// Format the category name - decode HTML entities for display, keep empty/none values as-is
	const rawCategory = categoryGroup.category;
	const formattedCategory = !rawCategory || rawCategory === CONST.SEARCH.CATEGORY_EMPTY_VALUE ? rawCategory : getDecodedCategoryName(rawCategory);
	categorySections[key] = {
	groupedBy: CONST.SEARCH.GROUP_BY.CATEGORY,
	transactions: [],
	transactionsQueryJSON,
	...categoryGroup,
	formattedCategory,
	keyForList: key,
	};
	}

TransactionGroupListItem mirrors this: for any non-expense-report group, its local transactions variable stays [] until transactionsSnapshot has loaded (which only happens once the row is expanded and refreshTransactions() runs).

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 152 to 175 in fec6b33

	let transactions: TransactionListItemType[];
	if (isExpenseReportType) {
	transactions = groupItem.transactions;
	} else if (!transactionsSnapshot?.data) {
	transactions = [];
	} else {
	const [sectionData] = getSections({
	type: CONST.SEARCH.DATA_TYPES.EXPENSE,
	data: transactionsSnapshot?.data,
	currentAccountID: currentUserDetails.accountID,
	currentUserEmail: currentUserDetails.email ?? '',
	translate,
	formatPhoneNumber,
	bankAccountList,
	isActionLoadingSet,
	cardFeeds,
	conciergeReportID,
	convertToDisplayString,
	}) as [TransactionListItemType[], number, boolean];
	transactions = sectionData.map((transactionItem) => ({
	...transactionItem,
	isSelected: selectedTransactionIDsSet.has(transactionItem.transactionID),
	}));
	}

isEmpty is derived from that same, not-yet-loaded transactions array, so it evaluates to true for every collapsed non-report group regardless of its actual count. isDisabledOrEmpty then folds that incorrect isEmpty into the value forwarded to each group header as isDisabled.

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 181 to 190 in fec6b33

	const isEmpty = transactions.length === 0;
	const isEmptyReportSelected = isEmpty && item?.keyForList && selectedTransactions[item.keyForList]?.isSelected;
	const isSelectAllChecked = isEmptyReportSelected || (selectedItemsLength === transactionsWithoutPendingDelete.length && transactionsWithoutPendingDelete.length > 0);
	const isIndeterminate = selectedItemsLength > 0 && selectedItemsLength !== transactionsWithoutPendingDelete.length;
	// Currently only the transaction report groups have transactions where the empty view makes sense
	const shouldDisplayEmptyView = isEmpty && isExpenseReportType;
	const isDisabledOrEmpty = isEmpty || isDisabled;

Every non-report group header (e.g. CategoryListItemHeader, used for group-by:category) is wired up with isDisabled={isDisabledOrEmpty}.

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 375 to 387 in fec6b33

	[CONST.SEARCH.GROUP_BY.CATEGORY]: (
	<CategoryListItemHeader
	category={groupItem as TransactionCategoryGroupListItemType}
	onCheckboxPress={handleSelectionButtonPress}
	isDisabled={isDisabledOrEmpty}
	columns={columns}
	canSelectMultiple={canSelectMultiple}
	isSelectAllChecked={isSelectAllChecked}
	isIndeterminate={isIndeterminate}
	onDownArrowClick={onExpandIconPress}
	isExpanded={isExpanded}
	/>
	),

BaseListItemHeader forwards that isDisabled value straight into the row's Checkbox's disabled prop, so while the group is collapsed the checkbox is literally non-interactive, even though the group has real expenses.

App/src/components/Search/SearchList/ListItem/BaseListItemHeader.tsx

Lines 150 to 160 in fec6b33

	{!!canSelectMultiple && (
	<Checkbox
	onPress={() => onCheckboxPress?.(item as unknown as TItem)}
	isChecked={isSelectAllChecked}
	isIndeterminate={isIndeterminate}
	disabled={!!isDisabled || item.isDisabledCheckbox}
	accessibilityLabel={translate('common.select')}
	containerStyle={styles.m0}
	sentryLabel={CONST.SENTRY_LABEL.SEARCH.GROUP_SELECT_ALL_CHECKBOX}
	/>
	)}

Tapping the expand arrow calls handleToggle(), which runs refreshTransactions() and loads the snapshot; once transactions becomes non-empty, isEmpty flips to false and the checkbox becomes enabled — matching the reported workaround. Expense-report groups aren't affected because ReportListItemHeader is passed the raw isDisabled (not isDisabledOrEmpty), and for isExpenseReportType the local transactions variable is already the group's real, pre-populated list rather than a lazily-fetched snapshot.

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

Compute isEmpty for non-report groups from the group's own count field (already present in the initial search payload) instead of the lazily-loaded transactions snapshot, so the checkbox reflects whether the group actually has expenses, not whether its detail rows have been fetched yet.

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Line 181 in fec6b33

const isEmpty = transactions.length === 0;

const groupItemCount = (groupItem as TransactionGroupListItemType & {count?: number}).count;
const isEmpty = isExpenseReportType ? transactions.length === 0 : groupItemCount === 0;

[lorretheboy]

Proposal

What is the root cause of that problem?

In grouped search, a group's child transactions are loaded lazily: they come from a per-group snapshot that is only fetched the first time the group is expanded. On narrow layouts (TransactionGroupListItem, used by both the legacy SearchList and the new ExpenseGroupedSearchView), the item derives its transactions solely from that snapshot, so before the group is ever expanded it is []:

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 152 to 156 in fb8771e

	let transactions: TransactionListItemType[];
	if (isExpenseReportType) {
	transactions = groupItem.transactions;
	} else if (!transactionsSnapshot?.data) {
	transactions = [];

That empty array makes the item consider the group "empty", and isDisabledOrEmpty is passed as isDisabled to the group header, which disables the checkbox — so tapping it does nothing:

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 181 to 190 in fb8771e

	const isEmpty = transactions.length === 0;
	const isEmptyReportSelected = isEmpty && item?.keyForList && selectedTransactions[item.keyForList]?.isSelected;
	const isSelectAllChecked = isEmptyReportSelected || (selectedItemsLength === transactionsWithoutPendingDelete.length && transactionsWithoutPendingDelete.length > 0);
	const isIndeterminate = selectedItemsLength > 0 && selectedItemsLength !== transactionsWithoutPendingDelete.length;
	// Currently only the transaction report groups have transactions where the empty view makes sense
	const shouldDisplayEmptyView = isEmpty && isExpenseReportType;
	const isDisabledOrEmpty = isEmpty || isDisabled;

App/src/components/Search/SearchList/ListItem/BaseListItemHeader.tsx

Lines 150 to 159 in fb8771e

	{!!canSelectMultiple && (
	<Checkbox
	onPress={() => onCheckboxPress?.(item as unknown as TItem)}
	isChecked={isSelectAllChecked}
	isIndeterminate={isIndeterminate}
	disabled={!!isDisabled || item.isDisabledCheckbox}
	accessibilityLabel={translate('common.select')}
	containerStyle={styles.m0}
	sentryLabel={CONST.SENTRY_LABEL.SEARCH.GROUP_SELECT_ALL_CHECKBOX}
	/>

The same wrong isEmpty also explains why the expand arrow selects the group instead: onExpandIconPress falls into the empty-group branch and calls onPress, which calls onSelectRow — and in mobile selection mode that toggles selection:

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 302 to 330 in fb8771e

	const onPress = (event?: ModifiedMouseEvent) => {
	if (isExpenseReportType || transactions.length === 0) {
	onSelectRow(item, transactionPreviewData, event);
	}
	if (!isExpenseReportType) {
	handleToggle();
	}
	};
	const onLongPress = () => {
	onLongPressRow?.(item, isExpenseReportType ? undefined : transactions);
	};
	const onExpandedRowLongPress = (transaction: TransactionListItemType) => {
	onLongPressRow?.(transaction as unknown as TItem);
	};
	const handleSelectionButtonPress = (val: TItem) => {
	onSelectionButtonPress?.(val, isExpenseReportType ? undefined : transactions);
	};
	const onExpandIconPress = () => {
	if (isEmpty && !shouldDisplayEmptyView) {
	onPress();
	// onPress handles handleToggle() for us, so we return early to avoid calling it twice
	return;
	}
	handleToggle();
	};

App/src/components/Search/hooks/useSearchListViewState.ts

Lines 85 to 94 in fb8771e

	const handleSelectRow = (item: SearchListItem, transactionPreviewData?: TransactionPreviewData, event?: ModifiedMouseEvent) => {
	if (isMobileSelectionModeEnabled) {
	if (item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	return;
	}
	toggle(item);
	return;
	}
	onSelectRow(item, transactionPreviewData, event);
	};

The wide-web counterpart (GroupHeader) already accounts for lazy loading — a group with a transactionsQueryJSON (children just not fetched yet) is not treated as empty — which is why this only breaks on narrow/native layouts:

App/src/components/Search/SearchList/ListItem/GroupHeader.tsx

Lines 174 to 177 in fb8771e

	const hasSnapshotTransactions = !isExpenseReportType && !!snapshotData && Object.keys(snapshotData).some((key) => key.startsWith(ONYXKEYS.COLLECTION.TRANSACTION));
	const isEmpty = groupItem.transactions.length === 0 && !hasSnapshotTransactions && !groupItem.transactionsQueryJSON;
	const isDisabled = item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
	const isDisabledOrEmpty = isEmpty || isDisabled;

PR #95028 did not change this narrow-layout path (its ExpenseGroupedSearchView wires the same handlers the legacy SearchList did); the bug lives in the shared TransactionGroupListItem, which is why it also reproduces in production.

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

In TransactionGroupListItem, mirror GroupHeader's lazy-load-aware emptiness so a not-yet-expanded group isn't treated as empty, and base the "selected as empty group" checkbox state on the loaded list length (like GroupHeader does with effectiveTransactions):

const isEmpty = transactions.length === 0 && groupItem.transactions.length === 0 && !groupItem.transactionsQueryJSON;
const isEmptyReportSelected = transactions.length === 0 && item?.keyForList && selectedTransactions[item.keyForList]?.isSelected;

With that, the checkbox is enabled for unexpanded groups; pressing it goes through the existing handleSelectionButtonPress → toggle(item, transactions) path, which already handles the no-loaded-children case by selecting the group by its key (the exact behavior wide web has today):

App/src/components/Search/SearchWriteActionsProvider.tsx

Lines 400 to 419 in fb8771e

	const currentTransactions = itemTransactions ?? item.transactions;
	applySelection(
	(selectedTransactions) => {
	if (currentTransactions.length === 0 && item.keyForList) {
	const reportKey = item.keyForList;
	if (item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	return selectedTransactions;
	}
	if (selectedTransactions[reportKey]?.isSelected) {
	const reducedSelectedTransactions: SelectedTransactions = {...selectedTransactions};
	delete reducedSelectedTransactions[reportKey];
	return reducedSelectedTransactions;
	}
	const [, emptyReportSelection] = mapEmptyReportToSelectedEntry(item);
	return {...selectedTransactions, [reportKey]: emptyReportSelection};
	}

And since isEmpty becomes false, the expand arrow stops falling into the empty-row branch in onExpandIconPress, so it just expands/collapses as expected. Fixing it here covers every caller (legacy SearchList and the new ExpenseGroupedSearchView) at once.

What alternative solutions did you explore? (Optional)

Falling back to groupItem.transactions when the snapshot isn't loaded (a full port of GroupHeader's effectiveTransactions) — works too, but the two-line emptiness fix is enough because the toggle action already handles groups whose children aren't loaded.

[Abdulloh0109]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 09:28:09 UTC.

Proposal

What is the root cause of that problem?

On mobile, a grouped expense search (type:expense group-by:category) does not use the sticky GroupHeader. In ExpenseGroupedSearchView, the split (sticky-header) layout is gated to wide web only:

App/src/components/Search/ExpenseGroupedSearchView.tsx

Lines 186 to 189 in fb8771e

	// Wide web layouts split each group into a sticky header row plus an expandable children-container row.
	// Computed here (not from the shared hook) because the split list feeds back into the hook as `listData`.
	const shouldSplit = !!groupBy && isLargeScreenWidth && getPlatform() === CONST.PLATFORM.WEB;
	const {listData, stickyHeaderIndices, childrenContainerIndices} = buildSplitGroupData(data, shouldSplit);

So on the native App every group renders through TransactionGroupListItem:

App/src/components/Search/ExpenseGroupedSearchView.tsx

Lines 336 to 368 in fb8771e

	// Non-split group rows: TransactionGroupListItem renders the whole group (header + children).
	const newTransactionID = item.keyForList ? newTransactionIDByItemKey.get(item.keyForList) : undefined;
	return (
	<AnimatedExitRow
	shouldApplyAnimation={index < listData.length - 1}
	hasItemsBeingRemoved={hasItemsBeingRemoved}
	>
	<TransactionGroupListItem
	showTooltip
	isFocused={isItemFocused}
	onSelectRow={handleSelectRow}
	onLongPressRow={onLongPressRow}
	onSelectionButtonPress={toggle}
	canSelectMultiple={canSelectMultiple}
	item={item}
	columns={columns}
	isDisabled={isRowDeleted(item)}
	groupBy={groupBy}
	searchType={type}
	lastPaymentMethod={lastPaymentMethod}
	personalPolicyID={personalPolicyID}
	userBillingGracePeriodEnds={userBillingGracePeriodEnds}
	ownerBillingGracePeriodEnd={ownerBillingGracePeriodEnd}
	nonPersonalAndWorkspaceCards={nonPersonalAndWorkspaceCards}
	onFocus={onFocus}
	newTransactionID={newTransactionID}
	onUndelete={handleUndelete}
	keyForList={item.keyForList}
	isFirstItem={index === firstVisibleIndex}
	isLastItem={index === lastVisibleIndex && !ListFooterComponent}
	/>
	</AnimatedExitRow>
	);

For a non–expense-report group, TransactionGroupListItem derives its transactions from the group's own Onyx snapshot, which is only fetched when the group is expanded. While the group is collapsed, transactionsSnapshot?.data is undefined, so transactions is an empty array:

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 152 to 175 in fb8771e

	let transactions: TransactionListItemType[];
	if (isExpenseReportType) {
	transactions = groupItem.transactions;
	} else if (!transactionsSnapshot?.data) {
	transactions = [];
	} else {
	const [sectionData] = getSections({
	type: CONST.SEARCH.DATA_TYPES.EXPENSE,
	data: transactionsSnapshot?.data,
	currentAccountID: currentUserDetails.accountID,
	currentUserEmail: currentUserDetails.email ?? '',
	translate,
	formatPhoneNumber,
	bankAccountList,
	isActionLoadingSet,
	cardFeeds,
	conciergeReportID,
	convertToDisplayString,
	}) as [TransactionListItemType[], number, boolean];
	transactions = sectionData.map((transactionItem) => ({
	...transactionItem,
	isSelected: selectedTransactionIDsSet.has(transactionItem.transactionID),
	}));
	}

isEmpty is then computed purely from that (not-yet-loaded) array, and folded into isDisabledOrEmpty:

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 181 to 190 in fb8771e

	const isEmpty = transactions.length === 0;
	const isEmptyReportSelected = isEmpty && item?.keyForList && selectedTransactions[item.keyForList]?.isSelected;
	const isSelectAllChecked = isEmptyReportSelected || (selectedItemsLength === transactionsWithoutPendingDelete.length && transactionsWithoutPendingDelete.length > 0);
	const isIndeterminate = selectedItemsLength > 0 && selectedItemsLength !== transactionsWithoutPendingDelete.length;
	// Currently only the transaction report groups have transactions where the empty view makes sense
	const shouldDisplayEmptyView = isEmpty && isExpenseReportType;
	const isDisabledOrEmpty = isEmpty || isDisabled;

isDisabledOrEmpty is passed as isDisabled to the group header (e.g. CategoryListItemHeader):

App/src/components/Search/SearchList/ListItem/TransactionGroupListItem.tsx

Lines 375 to 386 in fb8771e

	[CONST.SEARCH.GROUP_BY.CATEGORY]: (
	<CategoryListItemHeader
	category={groupItem as TransactionCategoryGroupListItemType}
	onCheckboxPress={handleSelectionButtonPress}
	isDisabled={isDisabledOrEmpty}
	columns={columns}
	canSelectMultiple={canSelectMultiple}
	isSelectAllChecked={isSelectAllChecked}
	isIndeterminate={isIndeterminate}
	onDownArrowClick={onExpandIconPress}
	isExpanded={isExpanded}
	/>

which forwards it to BaseListItemHeader, where it directly disables the group's checkbox:

App/src/components/Search/SearchList/ListItem/BaseListItemHeader.tsx

Lines 150 to 156 in fb8771e

	{!!canSelectMultiple && (
	<Checkbox
	onPress={() => onCheckboxPress?.(item as unknown as TItem)}
	isChecked={isSelectAllChecked}
	isIndeterminate={isIndeterminate}
	disabled={!!isDisabled || item.isDisabledCheckbox}
	accessibilityLabel={translate('common.select')}

So on a collapsed group the checkbox is rendered disabled, and tapping it does nothing — this is "unable to select the group." Tapping the expand arrow runs refreshTransactions, the snapshot loads, transactions becomes non-empty, isEmpty flips to false, the checkbox is enabled, and selection then works — which is exactly the reported "if tap on the expand arrow, group is selected."

This is App-specific because the wide-web path uses GroupHeader, whose isEmpty deliberately excludes groups that have transactions to load (!groupItem.transactionsQueryJSON), so its checkbox is never disabled just because the group is collapsed:

App/src/components/Search/SearchList/ListItem/GroupHeader.tsx

Lines 174 to 177 in fb8771e

	const hasSnapshotTransactions = !isExpenseReportType && !!snapshotData && Object.keys(snapshotData).some((key) => key.startsWith(ONYXKEYS.COLLECTION.TRANSACTION));
	const isEmpty = groupItem.transactions.length === 0 && !hasSnapshotTransactions && !groupItem.transactionsQueryJSON;
	const isDisabled = item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
	const isDisabledOrEmpty = isEmpty || isDisabled;

Note the selection layer itself already supports this case: toggle selects an unloaded group by its keyForList when it receives zero transactions, so the checkbox is the only thing standing in the way:

App/src/components/Search/SearchWriteActionsProvider.tsx

Lines 400 to 419 in fb8771e

	const currentTransactions = itemTransactions ?? item.transactions;
	applySelection(
	(selectedTransactions) => {
	if (currentTransactions.length === 0 && item.keyForList) {
	const reportKey = item.keyForList;
	if (item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	return selectedTransactions;
	}
	if (selectedTransactions[reportKey]?.isSelected) {
	const reducedSelectedTransactions: SelectedTransactions = {...selectedTransactions};
	delete reducedSelectedTransactions[reportKey];
	return reducedSelectedTransactions;
	}
	const [, emptyReportSelection] = mapEmptyReportToSelectedEntry(item);
	return {...selectedTransactions, [reportKey]: emptyReportSelection};
	}

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

In TransactionGroupListItem, stop treating a collapsed, lazily-loaded group as "empty" for the purpose of disabling its checkbox. Mirror the guard GroupHeader already uses so a group that has transactions to load (transactionsQueryJSON) is not considered empty.

Concretely, change the disabled computation at TransactionGroupListItem.tsx:190:

• from const isDisabledOrEmpty = isEmpty || isDisabled;
• to const isDisabledOrEmpty = isDisabled || (isEmpty && (isExpenseReportType || !groupItem.transactionsQueryJSON));

For expense-report groups (transactions are loaded inline, no lazy query) behavior is unchanged. For lazily-loaded category/tag/card/etc. groups, the checkbox stays enabled while collapsed, and tapping it calls toggle(item, []), which the selection provider already resolves by selecting the group via its keyForList (SearchWriteActionsProvider.tsx:400-419).

I'd keep isEmpty itself as-is (it's also used for the expand/empty-view logic) and only adjust the value that drives the header's isDisabled, to keep the change minimal and side-effect free.

What alternative solutions did you explore? (Optional)

• Unify the mobile and wide-web paths so the App also renders groups through GroupHeader (which already computes isEmpty correctly), removing the divergence entirely. Larger change with more regression surface.
• Enable the checkbox but eagerly fetch the group's transactions on checkbox press before toggling. Works, but adds a network round-trip for something the selection layer can already represent by group key, so I prefer the guard above.