[$250] Update the size of the Search input in popovers to use smaller sizes

[shawnborton]

Currently we use a large search input inside of popover menus that have search functionality. This is most commonly seen on the Spend page, as well as things like the emoji picker.

Let's update that search input to use the smaller input size that we use above our tables. Note that we use two different sizes: one for web/desktop, and one for mobile.

cc @Expensify/design @JmillsExpensify

@MelvinBot can you try to implement this please?

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022079225969349797387
• Upwork Job ID: 2079225969349797387
• Last Price Increase: 2026-07-20

[melvin-bot]

Current assignee @shawnborton is eligible for the NewFeature assigner, not assigning anyone new.

[melvin-bot]

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

[melvin-bot]

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

[wildan-m]

Proposal

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

Search inputs rendered inside popover menus — most visibly the filter popovers on the Spend page and the emoji picker — use the standard large form input size. Design wants these popover search inputs updated to the smaller search input size we already use above tables, keeping the two distinct sizes: one for web/desktop and a slightly taller one for mobile.

What is the root cause of that problem?

This is a design update rather than a bug, so the "root cause" is that no compact search-input variant exists for popovers — both popover search paths fall back to the default large text input sizing.

The Spend page filter popovers (single-select, multi-select, and the searchable selectors such as user/card/bank account) render their search field through the SelectionList's internal text input wrapper, which mounts the standard BaseTextInput with its default height and floating label:

App/src/components/SelectionList/components/TextInput.tsx

Line 153 in 2434b3f

<BaseTextInput

The emoji picker renders a standard TextInput directly, also at the default large size:

App/src/components/EmojiPicker/EmojiPickerMenu/index.tsx

Line 402 in 2434b3f

<TextInput

Meanwhile, the smaller size referenced by design already exists in TableSearchBar (the search input above tables). Its compact appearance comes from a placeholder instead of a floating label, a shorter wrapper height on web/desktop versus a taller one on narrow/mobile layouts, tighter container padding with the normal border radius, and the smaller label-size font:

App/src/components/Table/TableFilterBar/TableSearchBar.tsx

Lines 59 to 61 in 2434b3f

	const touchableInputWrapperStyle = [styles.mnw200, !shouldUseNarrowTableLayout ? styles.h8 : styles.h11];
	const textInputContainerStyles = [styles.border, styles.borderRadiusComponentNormal, styles.appBG, styles.p2, inputFocused && styles.borderColorFocus];

App/src/components/Table/TableFilterBar/TableSearchBar.tsx

Lines 75 to 78 in 2434b3f

	inputStyle={styles.textLabel}
	containerStyles={containerStyles}
	textInputContainerStyles={textInputContainerStyles}
	touchableInputWrapperStyle={touchableInputWrapperStyle}

None of that compact styling is shared or reachable from the popover search inputs, so they stay at the large default.

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

Introduce a reusable compact search-input variant and apply it in the searchable popovers:

1. Extract the compact search-input styling that TableSearchBar uses (placeholder instead of floating label, the shorter web/desktop wrapper height and taller mobile wrapper height, the tighter container padding with normal border radius, and the smaller label-size font) into a shared helper/style so both TableSearchBar and the popover inputs stay in sync.

2. Add a small context that marks a subtree as "rendered inside a popover". The SelectionList's internal text input wrapper reads that context, and when it is set it drops the floating label in favour of a placeholder and applies the shared compact styling instead of the default large input, choosing between the web/desktop and mobile heights via the narrow-layout check — matching the two sizes called out in the issue.

3. Provide that context from the popover containers rather than from each individual filter. Every Spend page filter dropdown (single-select, multi-select, and the searchable selectors such as user, card and bank account) renders its content through the shared filter popup container, and the advanced-filters popover renders its content through its own container, so wrapping those two containers covers every searchable popover at once. This avoids threading an extra prop through each of the dozen-plus selector components and keeps new popovers consistent by default.

4. Update the emoji picker's search TextInput to use the same compact styling directly (placeholder rather than label, the shared compact heights and font), since it does not go through SelectionList. Both the web/desktop and native variants of the picker need this.

Because the compact style is only supplied by popover containers, regular full-page SelectionList search inputs (pickers opened as full pages/RHP) keep their current large size, limiting the change strictly to popovers as requested.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96491-compact-popover-search-input?expand=1

What alternative solutions did you explore? (Optional)

Overriding styles ad-hoc at each popover call site (passing custom container/wrapper styles per usage) would work without touching SelectionList, but it duplicates the size constants in several places and risks the popover inputs drifting out of sync with the table search input; a single shared compact variant keeps the sizes consistent app-wide.

[MelvinBot]

Proposal

What is the root cause of that problem?

Search inputs inside popovers (Search filter dropdowns like From/To, the member selectors, and the emoji picker) all render through BaseTextInput, which forces the tall componentHeightLarge size (variables.inputHeight = 52px) whenever the input isn't multiline.

• SelectionList popovers (filters, "Find member") funnel through SelectionList/components/TextInput.tsx, which never passes a touchableInputWrapperStyle, so the input inherits the default 52px height.
• The emoji picker uses its own TextInput at EmojiPickerMenu/index.tsx — same default height.

The smaller "above-the-table" input we want to match is SearchPageInput.tsx. It's only small because it overrides the wrapper height via touchableInputWrapperStyle:

• Web/desktop → searchPageInputWideTouchableWrapper → height 34
• Mobile/narrow → searchPageInputNarrowTouchableWrapper → height 46

Popovers never opt into that override, so they stay at 52px.

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

Add an opt-in "compact" size to the shared popover search input and apply it only to popover surfaces — not a global change, which would shrink every list search in the app.

1. Add a reusable compact wrapper style in src/styles/index.ts (e.g. popoverSearchInputWrapper) that switches height by layout — 34 on wide, 46 on narrow — reusing the same values as the table inputs.
2. Let SelectionList's TextInput opt in. Add a boolean (e.g. shouldUseCompactInput) to TextInputOptions/SelectionList types and forward touchableInputWrapperStyle={styles.popoverSearchInputWrapper} plus the tighter vertical padding to BaseTextInput in SelectionList/components/TextInput.tsx. Gated by the flag so existing full-screen lists are untouched.
3. Turn it on at the popover call sites:
   • Search filter dropdowns via CommonFilterContentPopupWrapper.tsx (it already threads selectionListTextInputStyle — add the flag here).
   • Member-selector popovers ("Find member").
   • Emoji picker: pass the same touchableInputWrapperStyle to its TextInput.
4. Respect the two sizes by keying the wrapper height off useResponsiveLayout().shouldUseNarrowLayout — exactly how SearchPageInput distinguishes web/desktop (34) from mobile (46).

Because it's an opt-in flag scoped to popover surfaces, regular list screens keep the current 52px input.

Why opt-in and not a global edit

SelectionList's TextInput is shared by dozens of full-screen selection lists (contacts, categories, tags, etc.). Editing its default height directly would shrink all of those too, which isn't the ask. Gating on a flag keeps the blast radius to the three popover surfaces called out in the issue and makes review/QA straightforward.

What alternative solutions did you explore? (Optional)

Overriding height purely via containerStyle — rejected because the height lives on BaseTextInput's inner wrapper (componentHeightLarge), which only touchableInputWrapperStyle reaches, so containerStyle alone can't shrink it cleanly.

---

I held off on opening a PR because this touches a shared component and needs cross-platform (web + mobile) visual QA plus a design sign-off on the exact sizing. Once the approach is approved, reply @MelvinBot implement this and I'll open a draft PR wiring up the opt-in flag and the three popover surfaces.

[shawnborton]

@MelvinBot I think it's okay if we make this a global change in the app for all search inputs that appear above lists. Can you adjust your proposal based on that feedback and then implement?