[$250] Search should default to the type matching the current page context

[MelvinBot]

Problem

When a user initiates a keyword search from the Reports page, the search defaults to type:expense and switches to the Expenses view. This is unexpected — if you're on the Reports page, a keyword search should search within reports (type:expense-report), not expenses.

This is especially confusing when searching by report ID (e.g., R00AbC12deFG) from the Reports page. Instead of finding the matching report, it runs a keyword search for that string at the expense level. The user has to back out, return to Reports, and perform an explicit report ID search to find what they're looking for.

Expected Behavior

• Searching from the Expenses page should default to type:expense
• Searching from the Reports page should default to type:expense-report
• The search context should match whichever page/tab the user is currently viewing

Additional Context

There's also a related UX suggestion to make the search input above the table more visually connected to the table itself (acting as a keyword filter for the current view), while keeping the global search router separate with more visual presence.

Slack thread: https://expensify.slack.com/archives/C03U7DCU4/p1778073400727669

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022052714447950444652
• Upwork Job ID: 2052714447950444652
• Last Price Increase: 2026-05-08
• Automatic offers:
• FitseTLT | Contributor | 111413267

Issue Owner

Current Issue Owner: @FitseTLT

[wildan-m]

Proposal

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

When a user types a keyword into the per-page search input and submits, the resulting search ignores the current page's data type. From the Reports page (which displays type:expense-report), a keyword search ends up running as type:expense ..., dropping the user out of Reports and into Expenses. Searching for a report ID like R00VaF23anPD from Reports therefore returns no useful results — the lookup needs to happen in the report scope, not the expense scope.

The expected behavior is for the keyword search to inherit the data type of the page the user is on: from Reports → type:expense-report, from Expenses → type:expense, etc.

What is the root cause of that problem?

The submit handler used by the per-page search input (both wide and narrow layouts) is submitSearch in useSearchPageInput. It takes the raw text the user typed and passes it through getQueryWithUpdatedValues, which calls buildSearchQueryJSON on that raw text:

App/src/components/Search/SearchPageHeader/useSearchPageInput.tsx

Lines 120 to 140 in 338777e

	function submitSearch(queryString: SearchQueryString, shouldSkipAmountConversion = false) {
	const queryWithSubstitutions = getQueryWithSubstitutions(queryString, autocompleteSubstitutions);
	const updatedQuery = getQueryWithUpdatedValues(queryWithSubstitutions, shouldSkipAmountConversion);
	if (!updatedQuery) {
	return;
	}
	setSearchContext(true);
	Navigation.navigate(
	ROUTES.SEARCH_ROOT.getRoute({
	query: updatedQuery,
	rawQuery: shouldSkipAmountConversion ? undefined : queryWithSubstitutions,
	}),
	);
	onSubmit();
	if (updatedQuery !== originalInputQuery) {
	setTextInputValue('');
	setAutocompleteQueryValue('');
	}
	}

Because the raw text is just a free-text keyword with no type: filter, the parser falls through to its hard-coded default. The Peggy grammar initializes defaultValues.type to "expense" for any query that does not explicitly set a type:

App/src/libs/SearchParser/searchParser.peggy

Lines 60 to 66 in 338777e

	const defaultValues = {
	type: "expense",
	status: "",
	sortBy: "date",
	sortOrder: "desc",
	view: "table",

The hook already receives the current page's queryJSON (so it knows the active type, e.g. expense-report on the Reports page), but it never uses that value when assembling the new query. The current page context is effectively discarded on every submit, so every keyword-only search collapses to the parser's expense default regardless of where the user started.

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

In submitSearch inside src/components/Search/SearchPageHeader/useSearchPageInput.tsx, before parsing the user's input, check whether the input already contains an explicit type: filter. If it does not, prepend type:<currentPageType> using queryJSON.type from the props the hook already receives. The combined string is then passed through the existing substitution + getQueryWithUpdatedValues pipeline as today, so all other filters (status, policy, sort, etc.) keep working unchanged.

Concretely:

• Detect an existing type filter on the user's input by scanning for the type: token at the start of the string or after whitespace (the same syntax Peggy recognizes for defaultKey). A simple boundary-aware check is enough — we don't need to fully parse the input twice.
• When no type: is present, build the effective query as `type:${queryJSON.type} ${userInput}`. When the user did supply type: explicitly, leave the input untouched so power users can still override the page context.
• Leave the rest of submitSearch (substitutions, getQueryWithUpdatedValues, Navigation.navigate, setSearchContext) untouched.

This fix is local to the page-level search input hook, so it covers both SearchPageInputWide and SearchPageInputNarrow, which both consume useSearchPageInput. The global SearchRouter modal (top-of-app search) is intentionally not affected — that surface is page-context-agnostic and the issue's "Additional Context" notes the global router is treated as a separate concern.

Side effects to confirm:

• From the Expenses page (type:expense), behavior is unchanged because the prepended type matches the parser's existing default.
• From Reports (type:expense-report), Invoices, Trips, Tasks, or Chats, the search now correctly stays in the active scope.
• Saved-search and recent-search hashing is computed from the parsed SearchQueryJSON, which already carries type, so no hash drift is introduced — the submitted query just carries an explicit type: instead of relying on the implicit default.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/89989-search-page-input-type-filter?expand=1

What alternative solutions did you explore? (Optional)

• Changing the Peggy parser's defaultValues.type to be context-aware. Rejected: the parser is a pure function with no notion of UI state, and many call sites parse queries in non-UI contexts (saved searches, autocomplete, hashing). Threading page context into the parser would leak UI concerns into a shared utility.
• Fixing this at the navigation layer by intercepting ROUTES.SEARCH_ROOT.getRoute and rewriting q. Rejected: the route helper is also called from places that already produce fully-qualified queries (e.g. canned searches, saved searches, tab switches), so adding type-injection there would either double-prepend or require a "is this from per-page input" flag — strictly worse than the localized hook fix.
• Filling textInputValue with the full readable query (including type:...) on mount so that a submit naturally carries the type forward. Rejected: this changes the user-visible input from an empty placeholder to a pre-filled query string, which is a visible UX regression and not what the issue is asking for.

[melvin-bot]

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

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The Peggy grammar that powers all search parsing hard-codes type: "expense" in its per-parse initializer, and that constant is what fills in for any query the user submits without an explicit type: token:

https://github.com/Expensify/App/blob/main/src/libs/SearchParser/searchParser.peggy#L60-L67

getQueryWithUpdatedValues calls buildSearchQueryJSON → parseSearchQuery(query) with the raw user text only — no context, no second argument — so the grammar's expense default is the only thing the parser ever sees:

https://github.com/Expensify/App/blob/main/src/libs/SearchQueryUtils.ts#L599-L601 and https://github.com/Expensify/App/blob/main/src/libs/SearchQueryUtils.ts#L1863-L1874

The page-header input on the Reports/Expenses page submits through this exact path: https://github.com/Expensify/App/blob/main/src/components/Search/SearchPageHeader/useSearchPageInput.tsx#L120-L140

So when the user is on Reports and types R00AbC12deFG, the parser produces {type: "expense", filters: <keyword:R00AbC12deFG>} — the page context never reaches the parser, and the result navigates them out of Reports into Expenses.

The grammar already tracks whether the user typed a root key explicitly via rawFilterList, which is exactly how wasViewExplicitlySet distinguishes a user-supplied view: from the inherited default: https://github.com/Expensify/App/blob/main/src/libs/SearchQueryUtils.ts#L454-L472 — but no equivalent override path exists for type.

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

I'd push the context awareness down into the parser's defaultValues itself, by accepting a Peggy parse option (defaultType) and letting it override the grammar's hard-coded "expense". Peggy's generated peg$parse(input, options) already exposes the options argument inside the per-parse initializer block, so this is a minimal grammar change.

  // src/libs/SearchParser/searchParser.peggy — per-parse initializer
  const defaultValues = {
-     type: "expense",
+     type: (options && options.defaultType) || "expense",
      status: "",
      sortBy: "date",
      sortOrder: "desc",
      view: "table",
  };

After regenerating searchParser.js, thread the option through the one place that processes user submits:

- function getQueryWithUpdatedValues(query: string, shouldSkipAmountConversion = false) {
-     const queryJSON = buildSearchQueryJSON(query);
+ function getQueryWithUpdatedValues(query: string, shouldSkipAmountConversion = false, defaultType?: SearchDataTypes) {
+     const queryJSON = buildSearchQueryJSON(query, undefined, {defaultType});

buildSearchQueryJSON / getCachedSearchQueryJSON get a third arg that's forwarded to parseSearchQuery(query, {defaultType}), and the cache key is extended with defaultType so two parses of the same input under different contexts don't collide.

The page-header input already has the active page's queryJSON in scope, so the call site is one line:

- const updatedQuery = getQueryWithUpdatedValues(queryWithSubstitutions, shouldSkipAmountConversion);
+ const updatedQuery = getQueryWithUpdatedValues(queryWithSubstitutions, shouldSkipAmountConversion, queryJSON?.type);

The global SearchRouter.tsx does the same when the user is currently focused on a Search root (read it from useSearchStateContext().currentSearchQueryJSON?.type); when the router is opened from a non-search screen like the LHN it passes undefined and the parser keeps today's expense default — preserving the current behavior outside the bug's scope.

Why the parser layer instead of pre-parse string concatenation:

• Explicit type: from the user always wins for free. The grammar's existing defaultFilter rule overwrites defaultValues.type the moment it sees type:expense, and it pushes an entry into rawFilterList. An explicit override therefore never collides with defaultType — no string scan ("does the input contain type:?") needed, which keeps quoted strings, autocomplete substitutions, and other edge cases from leaking into the detection logic.
• One place to change. Every consumer of the parser (page header, global router, autocomplete, hash computation) reads from the same defaultValues, so the page-context default benefits all of them through a single seam.
• No mutation of the user's typed input. textInputValue stays exactly what the user wrote; only the parsed type field reflects context.

Tests in tests/unit/SearchQueryUtilsTest.ts:

• parseSearchQuery('R00ABC', {defaultType: 'expense-report'}).type === 'expense-report'
• parseSearchQuery('type:expense R00ABC', {defaultType: 'expense-report'}).type === 'expense-report' with rawFilterList containing the explicit type:expense (so explicit wins).
• Existing tests with no defaultType continue to default to expense.

What alternative solutions did you explore?

• Pre-parse string concatenation (type:${currentType} ${userInput} when the input doesn't contain type:). Simpler, but the "does the input contain type:?" check has to be implemented outside the grammar, where it doesn't see quoted strings, autocomplete substitutions, or escape sequences correctly. Putting the override in the parser's own defaultValues reuses the grammar's existing explicit-vs-default tracking and avoids a separate string scanner.
• Route-level R00… detection to short-circuit report-ID lookups regardless of page. Fixes only that one symptom and leaves the broader "search context should match the page" expectation untouched.
• A new Onyx.set('SEARCH_DEFAULT_TYPE', …) driven by the active route, read inside getDefaultSearchQueryJSON. Globally mutable parser state is harder to reason about than an explicit option threaded from the call site, and it would need careful invalidation of defaultSearchQueryJSON and the parser cache; the per-call option avoids both.

[github-actions]

⚠️ @dilshodmackbook-sketch 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.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The page-level search input submits through submitSearch in useSearchPageInput, which passes the raw text straight into getQueryWithUpdatedValues → buildSearchQueryJSON:

App/src/components/Search/SearchPageHeader/useSearchPageInput.tsx

Lines 120 to 140 in 338777e

	function submitSearch(queryString: SearchQueryString, shouldSkipAmountConversion = false) {
	const queryWithSubstitutions = getQueryWithSubstitutions(queryString, autocompleteSubstitutions);
	const updatedQuery = getQueryWithUpdatedValues(queryWithSubstitutions, shouldSkipAmountConversion);
	if (!updatedQuery) {
	return;
	}
	setSearchContext(true);
	Navigation.navigate(
	ROUTES.SEARCH_ROOT.getRoute({
	query: updatedQuery,
	rawQuery: shouldSkipAmountConversion ? undefined : queryWithSubstitutions,
	}),
	);
	onSubmit();
	if (updatedQuery !== originalInputQuery) {
	setTextInputValue('');
	setAutocompleteQueryValue('');
	}
	}

The text the user typed is just a keyword with no type: token, so the Peggy parser falls through to its hard-coded default and stamps type: "expense" on every keyword-only query:

App/src/libs/SearchParser/searchParser.peggy

Lines 61 to 67 in 338777e

	const defaultValues = {
	type: "expense",
	status: "",
	sortBy: "date",
	sortOrder: "desc",
	view: "table",
	};

The hook already receives the active page's queryJSON (which carries type: "expense-report" on the Reports page, type: "invoice" on Invoices, etc.), but submitSearch ignores that field. So submitting R00VaF23anPD from Reports collapses to type:expense R00VaF23anPD and lands the user on the Expenses tab with no results.

The same path is also taken when the user picks the "Find " entry from the autocomplete list — onListItemPress routes those through submitSearch too:

App/src/components/Search/SearchPageHeader/useSearchPageInput.tsx

Lines 186 to 188 in 338777e

	} else if (item.searchItemType === CONST.SEARCH.SEARCH_ROUTER_ITEM_TYPE.SEARCH) {
	submitSearch(item.searchQuery, item.keyForList !== CONST.SEARCH.SEARCH_ROUTER_ITEM_TYPE.FIND_ITEM);
	}

So both submission paths share the same bug and a single fix in submitSearch covers both.

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

Inject type:<currentPageType> into the submitted query when the user didn't supply one explicitly. type is in the parser's nonNegatableKeys set, so a plain word-boundary check on the token is sufficient — no need to re-parse.

 function submitSearch(queryString: SearchQueryString, shouldSkipAmountConversion = false) {
-    const queryWithSubstitutions = getQueryWithSubstitutions(queryString, autocompleteSubstitutions);
+    const hasExplicitType = /(^|\s)type:/.test(queryString);
+    const scopedQuery = hasExplicitType ? queryString : `type:${queryJSON.type} ${queryString}`;
+    const queryWithSubstitutions = getQueryWithSubstitutions(scopedQuery, autocompleteSubstitutions);
     const updatedQuery = getQueryWithUpdatedValues(queryWithSubstitutions, shouldSkipAmountConversion);

Why this location and not lower in the stack:

• submitSearch is the only place where we still have both the user's raw input (so we can detect an explicit type:) and the active page's queryJSON (so we know the right default). Pushing the logic into getQueryWithUpdatedValues or buildSearchQueryJSON would either need a new parameter threaded through every caller, or it would force page-context awareness into a pure utility used by saved searches, autocomplete, hashing, etc.
• The diff lives entirely inside the hook, so SearchPageInputWide, SearchPageInputNarrow, and the autocomplete-pick path all inherit the fix without further changes.
• Power users who type type:invoice ... from any page still get their explicit override respected.

The query hash for saved/recent searches is derived from the parsed JSON, which already carries type — the submitted query just makes the type explicit instead of relying on the implicit parser default, so no hash drift.

What alternative solutions did you explore? (Optional)

• Make Peggy's defaultValues.type page-aware. Rejected: the parser is also called from saved-search hashing, autocomplete preview, and getCurrentSearchQueryJSON — none of which have a meaningful "current page" concept. Threading UI state into a pure parser breaks the abstraction.
• Mutate the parsed JSON after buildSearchQueryJSON (override parsed.type if it equals the parser default). Rejected: there's no way to distinguish "user typed type:expense explicitly" from "parser filled the default" once parsing has run, so the heuristic would clobber valid explicit overrides on the Expenses page.
• Pre-fill the input with the readable form of queryJSON so the type carries forward on submit. Rejected: changes the user-visible empty placeholder into a pre-filled query string, which is a UX regression and not what the issue asks for.

[oqildev]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[dilshodmackbook-sketch]

proposal updated