[$250] Saved search is not visually highlighted as active when selected

[m-natarajan]

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

Action Performed:

1. Open the Expensify Android app
2. Go to Search / Reports page
3. Create a new saved search (apply filters → save it)
4. Rename the saved search
5. Tap/select the renamed saved search (or)
6. Open a old saved search with lot of reports

Expected Result:

The selected saved search should be highlighted at the top

Actual Result:

Search filters are applied correctly but no highlight/active state appears

Workaround:

Unknown

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

az_recorder_20260413_111420.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @neerajbachani

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043714851536917865
• Upwork Job ID: 2043714851536917865
• Last Price Increase: 2026-04-27

[MelvinBot]

Proposal

What is the root cause of that problem?

In SearchPageTabSelector.tsx, when saved searches are processed, activeKey is correctly set to the saved search's key at line 157-159 by matching queryJSON.hash. However, the subsequent loop over built-in menu items at lines 187-189 overwrites activeKey when a built-in item's similarSearchHash matches queryJSON.similarSearchHash. Since similarSearchHash only considers type/status/groupBy/policyID (not sort/view/columns), a saved search will almost always match a built-in tab, causing the overwrite.

The wide/desktop layout does not have this bug because useSearchTypeMenuSections.ts (lines 134-139) checks isSavedSearchActive first and returns activeItemIndex = -1, preventing built-in items from being highlighted. The mobile tab selector lacks this equivalent guard.

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

In SearchPageTabSelector.tsx, before the built-in items loop overwrites activeKey, check whether a saved search already claimed it. If a saved search is active (i.e., activeKey was set during the saved search mapping), skip the similarSearchHash assignment for built-in items. This mirrors the guard already used in useSearchTypeMenuSections.ts.

What alternative solutions did you explore? (Optional)

An alternative would be to reverse the processing order (built-in items first, then saved searches), but the current approach of adding a guard is more explicit and consistent with how the wide layout already handles it.

Supporting evidence

• Saved search sets activeKey: SearchPageTabSelector.tsx:157-159 — if (queryJSON && Number(key) === queryJSON.hash) { activeKey = key; }
• Built-in item overwrites it: SearchPageTabSelector.tsx:187-189 — if (queryJSON && item.similarSearchHash === queryJSON.similarSearchHash) { activeKey = item.key; }
• Wide layout guard (reference): useSearchTypeMenuSections.ts:134-139 — checks isSavedSearchActive and returns -1 early
• similarSearchHash definition: SearchQueryUtils.ts:479-536 — only hashes type, status, groupBy, policyID, and filter keys, so saved searches almost always collide with a built-in tab

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[ReaperOAK]

Proposal

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

When a user selects a saved search on the mobile app (Android/iOS), the correct search results are loaded but the saved search tab is not visually highlighted as active in the tab selector. This makes it impossible to tell which saved search is currently selected.

What is the root cause of that problem?

The bug is in src/pages/Search/SearchPageTabSelector.tsx, which is the narrow/mobile-only tab selector. There is an activeKey variable that determines which tab is highlighted. The logic sets activeKey in two places:

1. Saved search match (line ~157): During savedSearchesTabItems construction, if queryJSON.hash matches a saved search key, activeKey is correctly set:

   if (queryJSON && Number(key) === queryJSON.hash) {
       activeKey = key;
   }

2. Built-in tab match (line ~189): Later, in the section loop over built-in menu items, activeKey is unconditionally overwritten if similarSearchHash matches:

   if (queryJSON && item.similarSearchHash === queryJSON.similarSearchHash) {
       activeKey = item.key;
   }

The similarSearchHash (computed in src/libs/SearchQueryUtils.ts:getQueryHashes) only hashes type, status, groupBy, policyID, and filter keys — it intentionally excludes sortBy, sortOrder, columns, and view. This means a saved search will almost always produce the same similarSearchHash as its corresponding built-in tab (e.g., a saved "Expenses" search with custom sort matches the built-in "Expenses" tab). The built-in item's similarSearchHash match overwrites the saved search's activeKey, so the highlight snaps to the built-in tab instead of the saved search.

The wide/desktop layout does not have this bug because src/hooks/useSearchTypeMenuSections.ts (line ~134) includes an explicit guard:

const isSavedSearchActive = hash !== undefined && !!savedSearches && Object.keys(savedSearches).some((key) => Number(key) === hash);
if (isSavedSearchActive) {
    return -1; // no built-in item highlighted
}

The mobile SearchPageTabSelector lacks this equivalent guard.

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

In src/pages/Search/SearchPageTabSelector.tsx, add a guard to the built-in items' similarSearchHash check so it only sets activeKey when a saved search hasn't already claimed it. This is a one-line change:

Before (line ~189):

if (queryJSON && item.similarSearchHash === queryJSON.similarSearchHash) {
    activeKey = item.key;
}

After:

if (!activeKey && queryJSON && item.similarSearchHash === queryJSON.similarSearchHash) {
    activeKey = item.key;
}

Why this works:

• activeKey starts as '' (falsy). If a saved search matched during savedSearchesTabItems construction, activeKey is now a truthy string (the saved search key). The !activeKey guard prevents the built-in item from overwriting it.
• If no saved search matched, activeKey remains '' (falsy), so the built-in item match proceeds as normal — preserving existing behavior for non-saved-search tabs.
• This mirrors the exact pattern used in useSearchTypeMenuSections.ts where isSavedSearchActive short-circuits built-in item matching.

No other files need modification. The fix is fully backward-compatible.

What alternative solutions did you explore? (Optional)

Alternative: Reverse the processing order — process built-in items first, then let saved searches override. This would also fix the bug, but it requires reordering the section loop which is more invasive. The current typeMenuSections order is meaningful for tab display order, and coupling display order to activation priority is fragile.

Alternative: Introduce a separate isSavedSearchActive boolean (like the desktop hook does) and skip the entire built-in matching block. While more explicit, this adds unnecessary complexity for a single-condition guard. The !activeKey check achieves the same result with zero additional state and is immediately obvious in intent — if a saved search already claimed the highlight, don't let a built-in tab steal it.

The proposed !activeKey guard is the minimal, safest fix: one added condition, zero new variables, zero behavioral change for non-saved-search paths, and direct parity with how the desktop layout already handles this.

[daledah]

Proposal

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

Search filters are applied correctly but no highlight/active state appears.

What is the root cause of that problem?

In SearchPageTabSelector.tsx, activeKey is correctly set to the saved search's key when queryJSON.hash matches.

App/src/pages/Search/SearchPageTabSelector.tsx

Lines 157 to 159 in a367f8b

	if (queryJSON && Number(key) === queryJSON.hash) {
	activeKey = key;
	}

However, the subsequent loop over built-in menu items at lines 187-189 overwrites activeKey when a built-in item's similarSearchHash matches queryJSON.similarSearchHash. Since similarSearchHash only considers type/status/groupBy/policyID (not sort/view/columns), a saved search will almost always collide with a built-in tab, causing the overwrite.

App/src/pages/Search/SearchPageTabSelector.tsx

Lines 187 to 189 in a367f8b

	if (queryJSON && item.similarSearchHash === queryJSON.similarSearchHash) {
	activeKey = item.key;
	}

The wide/desktop layout does not have this bug because useSearchTypeMenuSections.ts lines 134-139 checks isSavedSearchActive first and returns activeItemIndex = -1, preventing built-in items from being highlighted. The mobile tab selector lacks this equivalent guard.

App/src/hooks/useSearchTypeMenuSections.ts

Lines 134 to 139 in a367f8b

	const activeItemIndex = useMemo(() => {
	const isSavedSearchActive = hash !== undefined && !!savedSearches && Object.keys(savedSearches).some((key) => Number(key) === hash);
	if (isSavedSearchActive) {
	return -1;
	}

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

In SearchPageTabSelector.tsx, compute isSavedSearchActive after the saved searches mapping, then use it as a guard before the built-in items loop can overwrite activeKey. This mirrors the guard already used in useSearchTypeMenuSections.ts (L134-L139).

+    const isSavedSearchActive =
+        queryJSON !== undefined &&
+        !!savedSearches &&
+        Object.keys(savedSearches).some((key) => Number(key) === queryJSON.hash);
+
     for (const section of typeMenuSections) {
         ...
-                if (queryJSON && item.similarSearchHash === queryJSON.similarSearchHash) {
+                if (!isSavedSearchActive && queryJSON && item.similarSearchHash === queryJSON.similarSearchHash) {
                     activeKey = item.key;
                 }
     }

What alternative solutions did you explore? (Optional)

An alternative is to simply check !activeKey as the guard, since activeKey is only set by a saved search match. However, using an explicit isSavedSearchActive flag is clearer and more consistent with the existing pattern in useSearchTypeMenuSections.ts.

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.

[github-actions]

⚠️ @daledah Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.