[Due for payment 2026-07-28] [$250] Selected values in Spend multi-select filters overflow beyond viewport instead of truncating

[m-natarajan]

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

---

Version Number: 9.4.33-0
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: @samranahm
Slack conversation (hyperlinked to channel name): #Open Source

Action Performed:

1. Navigate to the Spend tab.
2. Click Filters.
3. Open a multi-select filter (for example - Category).
4. Select enough values to fill the available horizontal space.
5. Continue selecting additional values.
6. Observe the selected filter bar behavior.

Expected Result:

The selected filter bar should maintain the available viewport width.
Filter pills should truncate after reaching a maximum width.
The UI should remain within the page boundaries without horizontal overflow.

Actual Result:

Selected filter pills continue expanding horizontally as more values are selected.
The filter bar overflows beyond the viewport.

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

Recording.3186.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022075627428470747688
• Upwork Job ID: 2075627428470747688
• Last Price Increase: 2026-07-10
• Automatic offers:
• ahmdshrif | Contributor | 111984760

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The Spend/Search filter pills are rendered by DropdownButton, and the label text (Category: a, b, c, …) grows unbounded as more values are selected (getButtonText).

The truncation intent is already coded — the label has numberOfLines={1} and the inner button has {maxWidth: 256} — but it isn't enforced on web/desktop. This is the classic React Native Web flexbox min-width: auto bug: a flex item won't shrink below the intrinsic width of its single-line (white-space: nowrap) text, and nothing in the wrapper chain sets minWidth: 0 or overflow: 'hidden'. So the text spills past the 256px box and the pill expands to the full string width, overflowing the wrapping filter row. Native RN doesn't use CSS min-width: auto, which is why this only reproduces on Chrome/Safari (Windows/macOS), matching the reported platforms.

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

In DropdownButton.tsx, add minWidth: 0 (and overflow: 'hidden') down the flex chain so the existing maxWidth: 256 + numberOfLines={1} actually clip the label with an ellipsis:

• Outer View (L69) and the Button flex-item wrapper style (L72): add minWidth: 0.
• Inner button innerStyles (L73): add minWidth: 0 (and overflow: 'hidden') alongside {maxWidth: 256}.
• CaretWrapper (L80) already has flex1/mw100; add minWidth: 0 so the constraint reaches the Text.

No minWidth0 style util exists yet, so add one (minWidth0: {minWidth: 0}) or inline {minWidth: 0}. Since min-width: auto is web-specific, applying minWidth: 0 is safe cross-platform (native ignores it).

What alternative solutions did you explore? (Optional)

Capping the row height / number of pill rows, or scrolling the row instead of wrapping — but that's a product decision beyond this bug; per-pill truncation to 256px matches the stated Expected Result.

Investigation details & evidence

• Pill component: DropdownButton.tsx:65-92, used by the Spend/Search filter bar via SearchFilterBar.tsx / SearchActionsBarWide.tsx.
• The Button's style prop becomes the pressable wrapper (the flex item) in Button/index.tsx; neither styles.button nor styles.buttonContainer sets minWidth/overflow.
• Style defs confirm no minWidth: 0 in the chain: flexShrink1 = {flexShrink: 1}, mw100 = {maxWidth: '100%'} only.
• Confidence: High on the component and root cause. Medium on the exact minimal set of nodes needing minWidth: 0 — worth confirming in-browser which level enforces the clip. Best validated with a browser repro before/after.

Possibly related: #93975 — "Web - Inbox - Inbox filters overlap with each other when filter word is long" looks like the same filter-overflow/truncation family and may share a fix.

---

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

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-10 17:28:55 UTC.

Proposal

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

On the Spend tab, when you open a multi-select filter (like Category) and keep selecting values, the selected-value chip in the filter bar keeps growing sideways instead of truncating. Past a certain number of selections the chip runs off the right edge of the screen and the bar overflows the viewport, when it should cap the chip's width and cut the text off with an ellipsis.

What is the root cause of that problem?

The selected filter chip is rendered by the shared DropdownButton component. When a value is selected it builds a single label string (getButtonText() joins the array into "Category: Food, Travel, ...") and hands it to a numberOfLines={1} <Text> that never wraps. That text is supposed to be bounded by a 256px cap on the Button's innerStyles, but the cap is being silently overridden.

Look at the style array at src/components/Search/FilterDropdowns/DropdownButton.tsx:73:

innerStyles={[..., {maxWidth: 256}, styles.mw100, styles.flexShrink1, ...]}

styles.mw100 is {maxWidth: '100%'} (src/styles/utils/sizing.ts:158). React Native flattens a style array left to right, and both entries set maxWidth, so the later mw100 wins. The intended absolute 256px cap gets clobbered into a percentage '100%'. A percentage max-width resolves against the parent's content width, which itself grows with the single-line text, so instead of clamping at 256px the chip expands to whatever the joined string needs and pushes past the viewport.

This is a regression. Commit 041a1c784b5 (PR #91746, 2026-06-24) reworked this filter bar to wrap onto a new line when needed and, in the process, appended mw100/flexShrink1 after the existing 256 cap on this line — which is what inverted the cap. There's also leftover mw100 from that same change on the outer View (line 69) and the CaretWrapper (line 80) that no longer does anything useful now that the inner cap is broken.

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

Remove styles.mw100 from the innerStyles array on line 73 so the absolute maxWidth wins again and numberOfLines={1} can truncate with an ellipsis. While there, swap the magic {maxWidth: 256} for the existing named constant variables.tabSelectorMaxTabLabelWidth (src/styles/variables.ts:224, value 256) — that's the same constant TabLabel.tsx already uses to cap and ellipsize its label, so this reads consistently instead of hardcoding the number.

DropdownButton is the single chip used for every filter type on both the Table/Spend and Search headers, so this one edit covers all the affected surfaces. The empty-state Display button (value is null) is unaffected since it just renders the short label.

One honest caveat: this is a layout bug, so I want to confirm the exact minimal CSS in a running wide web build before locking it. Dropping mw100 restores the 256px cap, but if the shrink chain needs a minWidth: 0 for the flex item to actually shrink below its content size on web, that's a one-line addition on the same chain. The root-cause file and the clobber mechanism are certain; I'd verify the precise edit against the browser to be safe. The missing regression test is a Search/Spend filter-bar case with many selected category names asserting the chip stays capped and the clear button remains present.

What alternative solutions did you explore? (Optional)

Bounding the whole chip (value button + divider + clear button) as one unit by moving the 256px cap to the outer View would technically stop the overflow, but it changes more layout than needed and risks squeezing the clear button; restoring the inner cap is the smaller, behavior-preserving fix. Reworking getButtonText() to truncate the joined string in JS was also an option, but keeping the full text and letting CSS ellipsize is cleaner and keeps the tooltip/full value intact.

[aswin-s]

Proposal

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

On Web (Windows/macOS Chrome/Safari), when a user opens a multi-select filter in the Spend tab (e.g. Category) and keeps selecting values, the resulting selected-filter pill in the filters bar keeps growing horizontally and pushes the row past the viewport instead of truncating at a maximum width. Expected: each filter pill should cap at a max width and truncate its text with an ellipsis so the bar stays within the viewport.

What is the root cause of that problem?

In src/components/Search/FilterDropdowns/DropdownButton.tsx:56-63, getButtonText() produces "${label}: ${value.join(', ')}" — a single ever-growing string. The truncation styles applied on the render tree are misplaced: maxWidth: 256 is set only on the Button's innerStyles (inner content wrapper) at line 73, while the Button's outer style (line 72) and the wrapping View (line 69) only get flexShrink1/mw100. Because the parent row in SearchActionsBarWide.tsx:40 uses flexWrap (so the row does not force children to shrink) and mw100 resolves to 100% of that unrestrained row, the Button's outer Pressable grows to fit its intrinsic content width, the maxWidth: 256 on the inner container gets stretched by its parent, and the numberOfLines={1} Text at line 85-89 never triggers ellipsis — producing the horizontal overflow.

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

1. In src/components/Search/FilterDropdowns/DropdownButton.tsx:69, add an explicit maxWidth: 256 (or a shared style constant) to the outer wrapping View, so the whole pill (button + close affordance) is capped, not just the inner content.
2. In src/components/Search/FilterDropdowns/DropdownButton.tsx:72, move/duplicate maxWidth: 256 onto the Button's outer style prop as well, so the outer Pressable itself is bounded (matching the inner cap) and the numberOfLines={1} Text can actually clip.
3. Ensure the Text at line 85 keeps numberOfLines={1} and add ellipsizeMode="tail" if not inherited, so the joined selected values render as Category: A, B, C… once the 256px cap is hit.
4. Verify the same fix covers all filter pill instances rendered by SearchFilterBar.tsx (UserDropdown, WorkspaceDropdown, FeedDropdown, CardDropdown, BankAccountDropdown, TaxRateDropdown, ReportDropdown, and the default DropdownButton) since they all funnel through this single DropdownButton component — one fix covers all filter keys.
5. Confirm SearchActionsBarWide.tsx:40's flexWrap still lets multiple capped pills wrap to a new line once the row is full, so the bar stays inside the viewport.

What alternative solutions did you explore? (Optional)

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-10 17:10:10 UTC.

Proposal

What is the root cause of that problem?

Every Spend filter chip is rendered through DropdownButton, and its label is just the selected values joined into a single growing string:

App/src/components/Search/FilterDropdowns/DropdownButton.tsx

Lines 56 to 63 in 89bfa7e

	const getButtonText = () => {
	if (!value?.length) {
	return label;
	}
	const selectedItems = Array.isArray(value) ? value.join(', ') : value;
	return `${label}: ${selectedItems}`;
	};

DropdownButton tries to keep that string bounded with a {maxWidth: 256} on the inner Button, but in the same innerStyles array styles.mw100 (which is maxWidth: '100%') is listed after the fixed cap:

App/src/components/Search/FilterDropdowns/DropdownButton.tsx

Lines 68 to 92 in 89bfa7e

	renderButton={({onPress, ref, isExpanded}) => (
	<View style={[styles.flexRow, styles.mw100, styles.flexShrink1]}>
	<Button
	ref={ref}
	style={styles.flexShrink1}
	innerStyles={[isExpanded && styles.buttonHoveredBG, {maxWidth: 256}, styles.mw100, styles.flexShrink1, innerStyles, shouldShowCloseButton && styles.pr2]}
	onPress={onPress}
	sentryLabel={sentryLabel}
	shouldRemoveRightBorderRadius={shouldShowCloseButton}
	{...(medium ? {medium: true} : {small: true})}
	>
	<CaretWrapper
	style={[styles.flex1, styles.mw100, caretWrapperStyle]}
	caretWidth={medium ? variables.iconSizeSmall : variables.iconSizeExtraSmall}
	caretHeight={medium ? variables.iconSizeSmall : variables.iconSizeExtraSmall}
	isActive={isExpanded}
	>
	<Text
	numberOfLines={1}
	style={[styles.textMicroBold, styles.flexShrink1, labelStyle]}
	>
	{getButtonText()}
	</Text>
	</CaretWrapper>
	</Button>

When the style array is flattened, the later entry wins, so maxWidth resolves to '100%' and the intended 256px cap never applies.

On the Spend tab, TableFilterBar renders each applied-filter chip with wrapperStyle={styles.flex1}:

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

Lines 45 to 58 in 89bfa7e

	const ActiveFilterChipsComponent = !!appliedFilters.length && (
	<View style={[styles.flexRow, styles.gap2, styles.flexWrap]}>
	{appliedFilters.map((filter) => (
	<DropdownButton
	key={filter.key}
	label={filter.label}
	value={filter.value}
	wrapperStyle={styles.flex1}
	PopoverComponent={TableFilterPopoverComponent}
	onClosePress={filter.onClosePress}
	/>
	))}
	</View>
	);

flex: 1 stretches the chip wrapper to the full row width, so the now-'100%' max width resolves against the entire viewport. With no minWidth: 0 on the flex chain, the single-line joined string (numberOfLines={1}) can't shrink/ellipsize below its content width, so the chip grows to the full string and spills past the viewport instead of truncating. The search page header uses DropdownButton without flex1, which is why the overflow surfaces on the Spend tab specifically.

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

Make the pixel cap actually win, and let the label clip inside it. In DropdownButton, move the fixed maxWidth after styles.mw100 and add minWidth: 0 so the flex row can shrink:

innerStyles={[isExpanded && styles.buttonHoveredBG, styles.mw100, styles.flexShrink1, {maxWidth: 256, minWidth: 0}, innerStyles, shouldShowCloseButton && styles.pr2]}

And allow the label Text to shrink and truncate within it (a common RN/web gotcha where numberOfLines won't ellipsize inside a flex row without minWidth: 0):

<Text
    numberOfLines={1}
    style={[styles.textMicroBold, styles.flexShrink1, {minWidth: 0}, labelStyle]}
>
    {getButtonText()}
</Text>

With the cap honored, every filter chip clips at 256px with an ellipsis (the expected result) even when a parent stretches it. Because all the specialized dropdowns (UserDropdown, CardDropdown, WorkspaceDropdown, ReportDropdown, etc.) funnel through the same DropdownButton, this fixes the overflow for every multi-select filter in one place. The 256 can optionally be promoted to a named variables value so it's a single source of truth.

What alternative solutions did you explore? (Optional)

• Localize the fix to TableFilterBar by swapping wrapperStyle={styles.flex1} for styles.flexShrink1, so each chip shrinks to its cap instead of stretching to the row width. This resolves the Spend-tab overflow with a one-line change, but leaves the mw100-overrides-maxWidth issue latent in DropdownButton for any other caller that stretches it.
• Show a count once several values are selected (e.g. Category: 3 selected) so a long string is never built in the first place. Visually cleaner, but it changes the label's product behavior, so it's better suited as a follow-up than as the overflow fix.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-10 17:09:22 UTC.

Proposal

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

In Spend > Filters, a multi-select filter pill (e.g. Category) keeps growing horizontally with every selected value instead of truncating at a max width, until the filter bar overflows the viewport.

What is the root cause of that problem?

A style-override regression from PR #91746 (commit 041a1c784b, "put filters on new line if needed"): the pill's 256px cap still exists in the code, but a later entry in the same style array silently overrides it. The chain:

1. Every selected-filter pill is DropdownButton. It joins all selected values into ONE string (Category: A, B, C, …), so the label grows with every selection:
   

   App/src/components/Search/FilterDropdowns/DropdownButton.tsx

   Lines 56 to 63 in 5ee0283

   	const getButtonText = () => {
   	if (!value?.length) {
   	return label;
   	}
   	const selectedItems = Array.isArray(value) ? value.join(', ') : value;
   	return `${label}: ${selectedItems}`;
   	};

2. That string renders in a single-line Text (numberOfLines={1} → white-space: nowrap on web):
   

   App/src/components/Search/FilterDropdowns/DropdownButton.tsx

   Lines 85 to 90 in 5ee0283

   	<Text
   	numberOfLines={1}
   	style={[styles.textMicroBold, styles.flexShrink1, labelStyle]}
   	>
   	{getButtonText()}
   	</Text>

3. The only thing that ever bounded the pill was {maxWidth: 256} in the Button's innerStyles. PR #91746 appended styles.mw100 (= maxWidth: '100%',

   App/src/styles/utils/sizing.ts

   Lines 158 to 160 in 5ee0283

   	mw100: {
   	maxWidth: '100%',
   	},

   ) AFTER it in the same array:
   

   App/src/components/Search/FilterDropdowns/DropdownButton.tsx

   Line 73 in 5ee0283

   innerStyles={[isExpanded && styles.buttonHoveredBG, {maxWidth: 256}, styles.mw100, styles.flexShrink1, innerStyles, shouldShowCloseButton && styles.pr2]}

   
   React Native flattens style arrays last-wins, so the effective cap became 100%, not 256px. Before that PR the pill truncated correctly.

4. Why 100% cannot stop the growth: the pill sits in a wrapping flex row (

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

   Lines 40 to 43 in 5ee0283

   	<View style={[styles.flexRow, styles.alignItemsCenter, styles.pRelative, styles.w100, styles.flexWrap, styles.flexShrink1, styles.gap2, styles.zIndex10]}>
   	<SearchPageInput queryJSON={queryJSON} />
   	<SearchFiltersBarWide queryJSON={queryJSON} />
   	</View>

   ). While that row measures its content to decide line breaks, a percentage max-width resolves against a parent width that is itself being measured, so it constrains nothing — the nowrap text's full string width becomes the pill's measured width. A definite px max-width DOES participate in that measurement, which is why the pre-#91746 code truncated. So each added value widens the pill, the line outgrows the page, and the ellipsis never fires because the Text is never width-constrained.

Affected paths (all flow through this one line):

• Wide filter bar (the repro): every pill type — Category/Tag/etc. multi-selects and all mapped dropdowns — renders via SearchFilterBar → DropdownButton:

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

  Lines 131 to 143 in 5ee0283

  	function SearchFilterBar({item}: {item: SearchFilter & FilterItem}) {
  	const Component = FILTER_COMPONENT_MAP[item.key] ?? DropdownButton;
  	return (
  	<Component
  	key={item.key}
  	label={item.label}
  	value={item.value}
  	PopoverComponent={item.PopoverComponent}
  	sentryLabel={item.sentryLabel}
  	onClosePress={item.onClosePress}
  	/>
  	);
  	}

• Narrow filter bar: same uncapped pill inside the horizontal FlatList — it grows arbitrarily long and scrolls instead of truncating:

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

  Lines 59 to 75 in 5ee0283

  	return (
  	<FlatList
  	horizontal
  	keyboardShouldPersistTaps="always"
  	style={[styles.flexRow, styles.overflowScroll, styles.flexGrow0, !!filters.length && styles.mb4]}
  	contentContainerStyle={[styles.flexRow, styles.flexGrow0, styles.gap2, styles.ph5, styles.alignItemsCenter]}
  	ref={scrollRef}
  	showsHorizontalScrollIndicator={false}
  	data={filters}
  	keyExtractor={(item) => item.key}
  	renderItem={renderFilterItem}
  	onEndReached={adjustScroll}
  	onEndReachedThreshold={0.75}
  	ListFooterComponent={filters.length > 0 ? <SearchFiltersClearButton onPress={clearFilters} /> : undefined}
  	/>
  	);
  	}

• Other consumers inheriting the same dead cap: the Display dropdown (

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

  Line 85 in 5ee0283

  <DropdownButton

  ), the new-style table filter bar, e.g. workspace members (

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

  Lines 46 to 57 in 5ee0283

  	<View style={[styles.flexRow, styles.gap2, styles.flexWrap]}>
  	{appliedFilters.map((filter) => (
  	<DropdownButton
  	key={filter.key}
  	label={filter.label}
  	value={filter.value}
  	wrapperStyle={styles.flex1}
  	PopoverComponent={TableFilterPopoverComponent}
  	onClosePress={filter.onClosePress}
  	/>
  	))}
  	</View>

  ), AddExistingExpense (

  App/src/pages/AddExistingExpense.tsx

  Line 345 in 5ee0283

  <DropdownButton

  ), and MoneyRequestReportTransactionList (

  App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx

  Lines 868 to 873 in 5ee0283

  	<DropdownButton
  	label={translate('search.display.groupBy')}
  	value={isLayoutMatrixSelected ? '' : (selectedGroupByItem?.text ?? '')}
  	PopoverComponent={groupByPopoverComponent}
  	/>
  	)}

  ).

This explains every symptom detail: pills "continue expanding as more values are selected" (the joined string grows, nothing bounds it) and the bar "overflows beyond the viewport" (the wrap row's line is sized by the nowrap text), while the code visibly intends a 256px cap that is currently dead.

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

Remove styles.mw100 from the Button's innerStyles in DropdownButton so the definite {maxWidth: 256} cap is effective again (

App/src/components/Search/FilterDropdowns/DropdownButton.tsx

Line 73 in 5ee0283

innerStyles={[isExpanded && styles.buttonHoveredBG, {maxWidth: 256}, styles.mw100, styles.flexShrink1, innerStyles, shouldShowCloseButton && styles.pr2]}

):

innerStyles={[isExpanded && styles.buttonHoveredBG, {maxWidth: 256}, styles.flexShrink1, innerStyles, shouldShowCloseButton && styles.pr2]}

With a real px bound, the existing numberOfLines={1} produces the intended ellipsis, and the bar stays inside the viewport. Regression safety: this restores the exact pre-#91746 cap while keeping everything that PR intended — the wrapper's mw100/flexShrink1 and the bar's flexWrap are untouched, so filters still wrap to new lines; no consumer passes its own innerStyles, so no other behavior changes.

Why the obvious spot-fixes do NOT work: adding ellipsis/numberOfLines is a no-op — it is already there (L86) and never fires because the pill is never width-constrained; adding flexShrink/minWidth: 0 up the chain cannot help because flex shrinking bottoms out at the content minimum, which for nowrap text is the full string width; and any percentage cap (mw100 on more wrappers) is ignored during the wrap row's intrinsic measurement. Only a definite px cap bounds the pill — and it already exists, just overridden one entry later in the same array.

What alternative solutions did you explore? (Optional)

1. Reorder the array so {maxWidth: 256} comes after styles.mw100 — equivalent, but leaving a dead mw100 invites the same last-wins accident again.
2. Summarize values in getButtonText() (e.g. Category: A, B +12 more) — a product/UX change that still needs the layout cap (one long single value overflows the same way).
3. Make the wide bar horizontally scrollable like the narrow bar — hides active filters and contradicts the wrap-to-new-line design #91746 just shipped.

[melvin-bot]

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

[MobileMage]

Proposal

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

On the Spend tab (the Search page), opening a multi-select quick-filter such as Category and selecting many values makes the filter pill grow horizontally without bound. Instead of truncating the pill at a maximum width, the selected-values text (Category: a, b, c, ...) keeps expanding and pushes the filter bar past the viewport, producing horizontal overflow on wide web layouts.

What is the root cause of that problem?

The Spend tab renders each quick filter through SearchFilterBar → DropdownButton, and DropdownButton was originally capped at a fixed 256px so the pill would truncate (numberOfLines={1} on the label Text). The regression is in the innerStyles array: {maxWidth: 256} is immediately followed by styles.mw100, and since React Native flattens style arrays left-to-right, the later entry wins — styles.mw100 is maxWidth: '100%', which silently overrides the 256px cap.

App/src/components/Search/FilterDropdowns/DropdownButton.tsx

Lines 69 to 73 in 5ee0283

	<View style={[styles.flexRow, styles.mw100, styles.flexShrink1]}>
	<Button
	ref={ref}
	style={styles.flexShrink1}
	innerStyles={[isExpanded && styles.buttonHoveredBG, {maxWidth: 256}, styles.mw100, styles.flexShrink1, innerStyles, shouldShowCloseButton && styles.pr2]}

A maxWidth: '100%' only constrains anything if some ancestor has a bounded, definite width. Here it has none. DropdownButton renders into FilterPopupButton, whose wrapper View uses style={wrapperStyle}, and SearchFilterBar passes no wrapperStyle. With no style, that View defaults to flexShrink: 0 and an auto (content-driven) width, so it grows to the pill's full max-content text width and overflows.

App/src/components/Search/FilterDropdowns/FilterPopupButton.tsx

Lines 102 to 106 in 5ee0283

	return (
	<View
	ref={anchorRef}
	style={wrapperStyle}
	>

So every 100% in the chain resolves against an unconstrained parent and collapses to "the full text width" — no cap at all. This was introduced by commit 041a1c784b5 ("put filters on new line if needed"), which changed the inner style from [..., {maxWidth: 256}, innerStyles, ...] to [..., {maxWidth: 256}, styles.mw100, styles.flexShrink1, innerStyles, ...]. Before that change the effective cap was the fixed 256px, so the pill truncated; after it, the effective cap became an unresolvable 100%, so the pill grows with content and overflows the page. It reproduces on the wide layout (desktop web from the repro), which uses this flex-wrap bar; the narrow layout renders the same pills inside a horizontally scrolling FlatList, so overflow there is just scroll.

I reproduced this on the Spend tab. Selecting 18 categories in the Category filter grows the selected-values pill to its full text width and it runs past the right edge of the window with no ellipsis, clipping mid-word instead of truncating at any bounded width. The underlying query state is correct: all 18 categories are present and the filter applies as expected, and nothing throws or logs an error, so this is not a data problem. Inspecting the pill confirms its computed maxWidth resolves to 100% of its container rather than the 256px cap the code intends, which lines up exactly with the root cause in DropdownButton.tsx: styles.mw100 (maxWidth: '100%') is applied after {maxWidth: 256} in the button's innerStyles array, so it wins during style flattening and the pixel cap is silently discarded. Since the wrapping button has no bounded ancestor, that unconstrained 100% resolves to the pill's full content width, which is what pushes it off-screen.

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

Restore the fixed pixel cap by reordering the innerStyles array in DropdownButton so {maxWidth: 256} is applied after styles.mw100, letting the absolute 256px value win again:

innerStyles={[isExpanded && styles.buttonHoveredBG, styles.mw100, styles.flexShrink1, {maxWidth: 256}, innerStyles, shouldShowCloseButton && styles.pr2]}

App/src/components/Search/FilterDropdowns/DropdownButton.tsx

Line 73 in 5ee0283

innerStyles={[isExpanded && styles.buttonHoveredBG, {maxWidth: 256}, styles.mw100, styles.flexShrink1, innerStyles, shouldShowCloseButton && styles.pr2]}

An absolute maxWidth needs no bounded ancestor: it caps the inner content at 256px, so the numberOfLines={1} label truncates with an ellipsis, and every auto-width parent (including the unconstrained FilterPopupButton wrapper) shrink-to-fits to ≤256px — no viewport overflow. This is safe for the other caller (TableFilterBar), which already constrains the wrapper via wrapperStyle={styles.flex1} and simply regains the intended 256px pill cap that existed before the June 24 change. On the wide bar the container is always wider than 256px, so the 100% cap was never the operative one anyway; keeping styles.mw100/flexShrink1 in place preserves the wrapping behavior that commit was after, while the pixel cap does the truncating.

What alternative solutions did you explore? (Optional)

Constraining FilterPopupButton's wrapper View with flexShrink: 1 + minWidth: 0 (or passing a bounded wrapperStyle from SearchFilterBar) would also let the 100% resolve, but it touches a View shared by every filter popup (date, amount, single-select, etc.), so it is broader and riskier than directly reversing the one-line style-ordering regression that caused the bug.

[godzillaxbox19982014-lgtm]

Proposal

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

Selected values in Spend multi-select filters overflow beyond viewport instead of truncating

What is the root cause of that problem?

I traced this to the path that handles truncated title:

• src/hooks/useSearchBulkActions.ts:498 (selectedCurrencies): const selectedCurrencies = [...selectedReports.map((report) => report.currency), ...Object.values(selectedTransactions).map((transaction) => transaction.currency)].filter(Boolean);
• src/components/Search/SearchSelectionProvider.tsx:91 (keys): totalSelectableItemsCount && totalSelectableItemsCount !== Object.keys(selectedTransactions).length ? false : prevState.areAllMatchingItemsSelected;
• src/components/Search/SearchSelectionProvider.tsx:150 (if): if (prevState.selectedReports.length === 0 && isEmptyObject(prevState.selectedTransactions) && !prevState.shouldTurnOffSelectionMode && !prevState.areAllMatchingItemsSelected) {
• src/components/Search/SearchSelectionProvider.tsx:249 (SearchSelectionProvider): return {isSelected: areAllMatchingItemsSelected || !!selectedTransactions[keyForList]?.isSelected};
• The full truncated title value reaches the row, but the visible text does not have a tight shrink/truncation boundary. With a long name, the text can expand the row instead of being clipped inside the neighbouring container constraints.

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

• Update src/hooks/useSearchBulkActions.ts:498 so the title/name row can shrink and the text node owns truncation with numberOfLines/tail ellipsis.
• Keep the full truncated title value available through src/components/Search/SearchSelectionProvider.tsx:91 for tooltip/accessibility, but constrain only the visible label so long workspace/report names cannot push neighbouring UI out of the container.
• Keep the change inside the UI, Forms, Lists, Accessibility surface and avoid changing platform-specific variants, screen reader behaviour.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/components/**/*.ts with a long truncated title value and assert the row stays inside its container.
2. Cover the counter-case near src/hooks/useSearchBulkActions.ts:498 so normal-length titles still render unchanged and the full value remains available to tooltip/accessibility.
3. Manually repeat the issue steps with a long workspace/report name and confirm the visible label truncates instead of overflowing.

What alternative solutions did you explore? (Optional)

• I would not patch each checkbox row independently; the selected-transaction/report sets need one shared select-all decision or the header and grouped rows will drift again.