[Due for payment 2026-07-23] [$250] Saved search item remains highlighted after delete confirmation modal is dismissed

[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.29-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: @FitseTLT
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to the Spend > Saved Searches list.
2. Select a saved search.
3. Click on the 3dot menu of other saved search.
4. Choose the Delete option.
5. When the confirmation modal appears, dismiss it (click outside the modal).
6. Observe the saved search item in the list.

Expected Result:

Dismissing the delete confirmation modal should return the UI to its previous state.
The saved search item should no longer remain highlighted unless it is actively selected.

Actual Result:

The saved search item remains highlighted after the delete confirmation modal is dismissed.

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

2026-07-08.01-15-45.mp4

Recording.3166.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074881801321392029
• Upwork Job ID: 2074881801321392029
• Last Price Increase: 2026-07-08

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

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

A saved search row stays visually highlighted after its 3-dot Delete confirmation modal is dismissed by clicking outside, even though a different saved search is the one actually selected.

What is the root cause of that problem?

The lingering highlight is the row's hover background, not the selected/active styling. Each saved search row is a MenuItem whose hover background is applied at MenuItem.tsx:892 (isHovered && ... && styles.hoveredComponentBG), driven by isHovered from ActiveHoverable.

ActiveHoverable only clears isHovered on a DOM onMouseLeave (ActiveHoverable.tsx:115), on scroll/tab-hidden, or when its isFocused prop goes false (ActiveHoverable.tsx:84-88). When you hover row B, open its menu and choose Delete, the ConfirmModal overlay covers row B — so no mouseleave ever reaches it. isFocused (which means "the screen is focused") stays true, so the auto-clear never runs. Dismissing the modal by clicking outside also dispatches no mouseleave to row B, so isHovered stays true and B remains highlighted. ActiveHoverable has no awareness of a modal/overlay appearing over it.

Investigation details & evidence

• The selected ("focused") styling is ruled out: it is static (Number(key) === hash) and correctly stays on the selected row A — SavedSearchList.tsx derives isItemFocused from the hash only.
• SavedSearchItemThreeDotMenu applies no row-level highlight itself; it just renders ThreeDotsMenu, so a "menu-open" highlight is not the cause.
• ThreeDotsMenu already reads modal visibility via useOnyx(ONYXKEYS.MODAL) at ThreeDotsMenu/index.tsx:62 — the same signal ActiveHoverable could use.
• Repro platforms are all mouse-based (Windows/Mac Chrome/Safari), consistent with a stuck hover state.

Data flow: hover B → isHovered=true → hover bg → open 3-dot → Delete → ConfirmModal overlay covers B → no mouseleave → dismiss modal (no mouseleave either) → isHovered never reset → B stays highlighted.

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

Make the hover state reset when a modal covers the element. In ActiveHoverable.tsx, subscribe to useOnyx(ONYXKEYS.MODAL) and call setIsHovered(false) when a modal becomes visible (mirroring the pattern already used in ThreeDotsMenu). This is robust and fixes the whole class of "hoverable list row stays highlighted under a modal" bugs.

A narrower alternative: thread an isFocused/shouldReset prop from SavedSearchList → MenuItemList → MenuItem → Hoverable that flips to false while the delete modal is open, leveraging the existing clear-on-isFocused-false effect at ActiveHoverable.tsx:84-88.

Confidence: High — code evidence explains all reported symptoms; the fix is entirely within the App repo.

What alternative solutions did you explore? (Optional)

Resetting hover in the delete-flow callbacks (useDeleteSavedSearch / useConfirmModal) was considered but rejected — it would only patch this one flow, not the general modal-over-hovered-row case.

---

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

[nabi-ebrahimi]

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

Proposal

What is the root cause of that problem?

The desktop saved-search row highlight is driven by MenuItem hover/active state: MenuItem wraps each row in Hoverable, and applies active/hover background whenever focused || isHovered is true

App/src/components/MenuItem.tsx

Lines 869 to 892 in 7a1d730

	<Hoverable isFocused={isFocused}>
	{(isHovered) => (
	<PressableWithSecondaryInteraction
	onPress={shouldCheckActionAllowedOnPress ? callFunctionIfActionIsAllowed(onPressAction, isAnonymousAction) : onPressAction}
	onPressIn={() => shouldBlockSelection && shouldUseNarrowLayout && canUseTouchScreen() && ControlSelection.block()}
	onPressOut={ControlSelection.unblock}
	onSecondaryInteraction={copyable && !deviceHasHoverSupport ? secondaryInteraction : onSecondaryInteraction}
	wrapperStyle={outerWrapperStyle}
	activeOpacity={!interactive ? 1 : variables.pressDimValue}
	opacityAnimationDuration={0}
	testID={pressableTestID}
	style={({pressed}) =>
	[
	containerStyle,
	combinedStyle,
	!interactive && styles.cursorDefault,
	isCompact && styles.alignItemsCenter,
	isCompact && styles.optionRowCompact,
	isCompactPopoverItem && (description ? styles.compactPopoverMenuItemBase : styles.compactPopoverMenuItem),
	!shouldRemoveBackground &&
	StyleUtils.getButtonBackgroundColorStyle(getButtonState(focused || isHovered, pressed, success, disabled, interactive), true),
	...(Array.isArray(wrapperStyle) ? wrapperStyle : [wrapperStyle]),
	shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled,
	isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

. In the wide saved-search list, each saved search row renders a nested three-dot menu as rightComponent

App/src/pages/Search/SavedSearchList.tsx

Lines 83 to 91 in 7a1d730

	rightComponent: (
	<SavedSearchItemThreeDotMenu
	menuItems={getOverflowMenu(title, Number(key), item.query)}
	isDisabledItem={item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE}
	hideProductTrainingTooltip={index === 0 && shouldShowSavedSearchTooltip ? hideSavedSearchTooltip : undefined}
	shouldRenderTooltip={index === 0 && shouldShowSavedSearchTooltip}
	renderTooltipContent={renderSavedSearchTooltip}
	isCopied={isCopied}
	/>

through MenuItemList

App/src/pages/Search/SavedSearchList.tsx

Lines 199 to 207 in 7a1d730

	return (
	<MenuItemList
	menuItems={savedSearchesMenuItems}
	wrapperStyle={[styles.sectionMenuItem(shouldUseNarrowLayout), styles.searchTypeMenuItemPadding]}
	icon={expensifyIcons.Bookmark}
	iconWidth={variables.iconSizeNormal}
	iconHeight={variables.iconSizeNormal}
	shouldUseSingleExecution
	/>

. When the user selects an item from that nested popover, the popover can close or re-render while the pointer is still over its portal-rendered menu content. Because the popover is rendered without a backdrop overlay and is removed above the still-hovered row, the row’s ActiveHoverable does not receive a normal mouseleave event when the popover element is removed

App/src/components/ThreeDotsMenu/index.tsx

Lines 204 to 214 in 86ac9fa

	onClose={hidePopoverMenu}
	onModalHide={() => setRestoreFocusType(undefined)}
	isVisible={isPopupMenuVisible && !isBehindModal && isContainerFocused}
	anchorPosition={position ?? anchorPosition ?? {horizontal: 0, vertical: 0}}
	anchorAlignment={anchorAlignment}
	onItemSelected={(item) => {
	setRestoreFocusType(CONST.MODAL.RESTORE_FOCUS_TYPE.PRESERVE);
	hidePopoverMenu(item);
	}}
	menuItems={menuItems}
	withoutOverlay={!shouldOverlay}

,

App/src/components/PopoverMenu/index.tsx

Lines 417 to 432 in 86ac9fa

	} else if (selectedItem.shouldCloseModalOnSelect === false) {
	onItemSelected?.(selectedItem, index, event);
	selectedItem.onSelected?.();
	setFocusedIndex(-1);
	} else if (selectedItem.shouldCallAfterModalHide && (!isSafari() || shouldAvoidSafariException)) {
	onItemSelected?.(selectedItem, index, event);
	close(
	() => {
	selectedItem.onSelected?.();
	},
	undefined,
	selectedItem.shouldCloseAllModals,
	);
	} else {
	onItemSelected?.(selectedItem, index, event);
	selectedItem.onSelected?.();

; this is the same browser/React behavior described here react/react#19637 (comment). Since ActiveHoverable clears hover on onMouseLeave, scroll/visibility changes, or isFocused=false, the non-selected saved-search row can keep its stale isHovered highlight

App/src/components/Hoverable/ActiveHoverable.tsx

Lines 53 to 115 in 86ac9fa

	const scrollingListener = DeviceEventEmitter.addListener(CONST.EVENTS.SCROLLING, (scrolling: boolean) => {
	isScrollingRef.current = scrolling;
	if (scrolling && isHoveredRef.current) {
	isHoveredRef.current = false;
	setIsHovered(false);
	onHoverOut?.();
	} else if (!scrolling && elementRef.current?.matches(':hover')) {
	isHoveredRef.current = true;
	setIsHovered(true);
	onHoverIn?.();
	}
	});
	return () => scrollingListener.remove();
	}, [shouldHandleScroll, onHoverIn, onHoverOut]);
	useEffect(() => {
	const handleVisibilityChange = () => {
	if (document.visibilityState === 'hidden') {
	isVisibilityHidden.current = true;
	setIsHovered(false);
	} else {
	isVisibilityHidden.current = false;
	}
	};
	document.addEventListener('visibilitychange', handleVisibilityChange);
	return () => document.removeEventListener('visibilitychange', handleVisibilityChange);
	}, []);
	useEffect(() => {
	if (isFocused) {
	return;
	}
	setIsHovered(false);
	}, [isFocused]);
	const handleMouseEvents = useCallback(
	(type: 'enter' | 'leave') => () => {
	if (shouldFreezeCapture) {
	return;
	}
	const newHoverState = type === 'enter';
	isHoveredRef.current = newHoverState;
	isVisibilityHidden.current = false;
	updateIsHovered(newHoverState);
	},
	[shouldFreezeCapture, updateIsHovered],
	);
	const child = useMemo(() => getReturnValue(children, isHovered), [children, isHovered]);
	const {onMouseEnter, onMouseLeave} = child.props as OnMouseEvents;
	return cloneElement(child, {
	ref: mergeRefs(elementRef, ref, child.props.ref),
	onMouseEnter: (e: React.MouseEvent) => {
	handleMouseEvents('enter')();
	onMouseEnter?.(e);
	},
	onMouseLeave: (e: React.MouseEvent) => {

. This also explains why Share reproduces the issue too, because it uses the same popover path without opening the delete confirmation modal

App/src/libs/SearchUIUtils.ts

Lines 4539 to 4551 in 7a1d730

	onSelected: () => {
	shareProps?.onShare();
	},
	icon: shareProps?.isCopied ? icons.Checkmark : icons.LinkCopy,
	shouldShowRightIcon: false,
	shouldShowRightComponent: false,
	disabled: shareProps?.isCopied,
	shouldGreyOutWhenDisabled: false,
	shouldUseDefaultCursorWhenDisabled: true,
	shouldCloseModalOnSelect: false,
	},
	{
	text: translate('common.delete'),

. The stale hover highlight is separate from the saved-search focused value, which only comes from the active route hash

App/src/pages/Search/SavedSearchList.tsx

Lines 72 to 73 in 7a1d730

	const isItemFocused = Number(key) === hash;
	const baseMenuItem: SavedSearchMenuItem = createBaseSavedSearchMenuItem(item, key, index, title, isItemFocused);

,

App/src/libs/SearchUIUtils.ts

Lines 4784 to 4792 in 7a1d730

	function createBaseSavedSearchMenuItem(item: SaveSearchItem, key: string, index: number, title: string, isFocused: boolean): SavedSearchMenuItem {
	return {
	key,
	title,
	hash: key,
	query: item.query,
	shouldShowRightComponent: true,
	focused: isFocused,
	pendingAction: item.pendingAction,

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

Add an optional cleanup/finalizer callback to useDeleteSavedSearch()'s showDeleteModal handler and run it when the confirmation modal resolves, regardless of whether the user confirms or dismisses. Keep the existing delete/navigation behavior unchanged for confirmed deletes. In addition, trigger the same scoped cleanup from the wide saved-search three-dot popover close/item-selection lifecycle, so the affected row’s hover state is also reset for actions that do not open the confirmation modal, such as Share. This keeps the cleanup scoped to the affected saved-search row and avoids re-adding a global ONYXKEYS.MODAL subscription.

In SavedSearchList, wrap showDeleteModal for the wide saved-search overflow menu so it tracks the hash whose delete confirmation is open and clears that tracking in the new finalizer. While that hash is being confirmed, force the affected row’s hover controller to reset by passing a per-item screen-focus override through MenuItemList/MenuItem for that saved-search row. MenuItemList currently always passes its own useIsFocused() value to every MenuItem, so update it to preserve the current default but allow an explicit item-level isFocused override when a caller needs to reset a single row’s hover state.

This keeps the active saved-search highlight based on the route hash, while ensuring the temporary hover highlight from opening the three-dot delete confirmation is cleared when the modal is dismissed.

What alternative solutions did you explore? (Optional)

I considered only calling the existing closeMenu callback from the wide path, but the wide path’s popover is already closed by ThreeDotsMenu; the stale state is the parent row’s Hoverable state, so the fix needs to reset that row’s hover state after the confirm modal lifecycle completes.

I also considered handling the cleanup entirely within the wide saved-search popover interaction layer.

With this approach, when an item is selected from SavedSearchItemThreeDotMenu, it would notify SavedSearchList of the affected saved-search hash. SavedSearchList would then temporarily pass isFocused={false} for that specific row through MenuItemList and MenuItem, leveraging ActiveHoverable's existing isFocused=false effect to clear the stale isHovered state. On the following render, the temporary reset hash would be cleared so that the normal route-based focused value remains unchanged.

This approach would still avoid reintroducing the global ONYXKEYS.MODAL subscription while keeping the reset scoped to the affected saved-search row. It also differs from a DOM :hover re-sync solution because it does not require a new global popover-close event or the plumbing of a row DOM ref.

Fixed Demo:

Screencast.From.2026-07-08.21-58-06.mp4

[samranahm]

Proposal

What is the root cause of that problem?

When a user opens the three-dot overflow menu of a saved search and chooses Delete, the row that owns that menu is marked as the active/highlighted item, and a confirmation modal is shown through useDeleteSavedSearch().showDeleteModal. That active key is only cleared when the user confirms or cancels through the modal buttons, not when the modal is dismissed by clicking the backdrop.

In SearchTypeMenuNarrow, the active row is tracked by savedSearchToModifyKey set through setSavedSearchToModifyKey, and the delete flow uses showDeleteModal from useDeleteSavedSearch:

App/src/pages/Search/SearchTypeMenuNarrow.tsx

Lines 79 to 158 in f36b4c5

	function SearchTypeMenuNarrow({queryJSON, onTabPress}: SearchTypeMenuNarrowProps) {
	const {isOffline} = useNetwork();
	const navigation = useNavigation();
	const {translate, localeCompare} = useLocalize();
	const {typeMenuSections, activeKey: activeTypeMenuKey} = useSearchTypeMenuSections({
	hash: queryJSON?.hash,
	similarSearchHash: queryJSON?.similarSearchHash,
	sortBy: queryJSON?.sortBy,
	sortOrder: queryJSON?.sortOrder,
	type: queryJSON?.type,
	});
	const personalDetails = usePersonalDetails();
	const feedKeysWithCards = useFeedKeysWithAssignedCards();
	const [restoreFocusType, setRestoreFocusType] = useState<BaseModalProps['restoreFocusType']>();
	const [reports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);
	const [allFeeds] = useOnyx(ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER);
	const [allPolicies] = useOnyx(ONYXKEYS.COLLECTION.POLICY);
	const [cardList] = useOnyx(ONYXKEYS.CARD_LIST);
	const [bankAccountList] = useOnyx(ONYXKEYS.BANK_ACCOUNT_LIST);
	const [workspaceCardList] = useOnyx(ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST);
	const [savedSearches] = useOnyx(ONYXKEYS.SAVED_SEARCHES);
	const isFocused = useIsFocused();
	const {counts: reportCounts} = useTodoCounts(isFocused);
	const [currentUserAccountID = -1] = useOnyx(ONYXKEYS.SESSION, {selector: accountIDSelector});
	const reportAttributes = useReportAttributes();
	const taxRates = getAllTaxRates(allPolicies);
	const cardsForSavedSearchDisplay = mergeCardListWithWorkspaceFeeds(workspaceCardList ?? CONST.EMPTY_OBJECT, cardList);
	const savedSearchTitles = useSavedSearchTitles({
	savedSearches,
	PersonalDetails: personalDetails,
	reports,
	taxRates,
	cardList: cardsForSavedSearchDisplay,
	cardFeeds: allFeeds,
	policies: allPolicies,
	currentUserAccountID,
	translate,
	feedKeysWithCards,
	reportAttributes,
	bankAccountList,
	enabled: !!queryJSON,
	});
	const [savedSearchToModifyKey, setSavedSearchToModifyKey] = useState<string | null>(null);
	const menuAnchorRef = useRef<View>(null);
	const {showDeleteModal} = useDeleteSavedSearch();
	const {copiedHash, handleShare} = useShareSavedSearch();
	const expensifyIcons = useMemoizedLazyExpensifyIcons([
	'Receipt',
	'MoneyBag',
	'CreditCard',
	'MoneyHourglass',
	'CreditCardHourglass',
	'Bank',
	'User',
	'Folder',
	'Basket',
	'CalendarSolid',
	'Bookmark',
	'Pencil',
	'Trashcan',
	'LinkCopy',
	'Checkmark',
	'Document',
	'ThumbsUp',
	'CheckCircle',
	]);
	const queryMap = new Map<string, {query: string; name?: string}>();
	const tabItems: TabSelectorBaseItem[] = [];
	const savedSearchesPopoverMenuItems: Record<string, PopoverMenuItem[]> = {};
	let activeKey = '';
	const savedSearchesTabItems: TabSelectorBaseItem[] = savedSearches
	? Object.entries(savedSearches)
	.map(([key, item]): TabSelectorBaseItem | null => {

SavedSearchList follows the same pattern, building the overflow menu with getOverflowMenuUtil and passing showDeleteModal, while relying on the popover/active state to highlight the row:

App/src/pages/Search/SavedSearchList.tsx

Lines 105 to 184 in f36b4c5

	function SavedSearchList({hash, areAllSectionsExpanded}: SavedSearchListProps) {
	const styles = useThemeStyles();
	const {translate, localeCompare} = useLocalize();
	const {shouldUseNarrowLayout} = useResponsiveLayout();
	const {isVisuallyCollapsed} = useSearchSidebarCollapse();
	const isFocused = useIsFocused();
	const [savedSearches] = useOnyx(ONYXKEYS.SAVED_SEARCHES);
	const [allPolicies] = useOnyx(ONYXKEYS.COLLECTION.POLICY);
	const personalDetails = usePersonalDetails();
	const [cardList] = useOnyx(ONYXKEYS.CARD_LIST);
	const [workspaceCardList] = useOnyx(ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST);
	const [reports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);
	const [allFeeds] = useOnyx(ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER);
	const [bankAccountList] = useOnyx(ONYXKEYS.BANK_ACCOUNT_LIST);
	const feedKeysWithCards = useFeedKeysWithAssignedCards();
	const [currentUserAccountID = -1] = useOnyx(ONYXKEYS.SESSION, {selector: accountIDSelector});
	const reportAttributes = useReportAttributes();
	const {showDeleteModal} = useDeleteSavedSearch();
	const {
	shouldShowProductTrainingTooltip: shouldShowSavedSearchTooltip,
	renderProductTrainingTooltip: renderSavedSearchTooltip,
	hideProductTrainingTooltip: hideSavedSearchTooltip,
	} = useProductTrainingContext(CONST.PRODUCT_TRAINING_TOOLTIP_NAMES.RENAME_SAVED_SEARCH, isFocused && areAllSectionsExpanded);
	const expensifyIcons = useMemoizedLazyExpensifyIcons(['Bookmark', 'Pencil', 'Trashcan', 'LinkCopy', 'Checkmark']);
	const {copiedHash, handleShare} = useShareSavedSearch();
	const taxRates = getAllTaxRates(allPolicies);
	const cardsForSavedSearchDisplay = mergeCardListWithWorkspaceFeeds(workspaceCardList ?? CONST.EMPTY_OBJECT, cardList);
	const savedSearchTitles = useSavedSearchTitles({
	savedSearches,
	PersonalDetails: personalDetails,
	reports,
	taxRates,
	cardList: cardsForSavedSearchDisplay,
	cardFeeds: allFeeds,
	policies: allPolicies,
	currentUserAccountID,
	translate,
	feedKeysWithCards,
	reportAttributes,
	bankAccountList,
	});
	const getOverflowMenu = (itemName: string, itemHash: number, itemQuery: string) =>
	getOverflowMenuUtil(expensifyIcons, itemName, itemHash, itemQuery, translate, showDeleteModal, false, undefined, {
	onShare: () => handleShare(itemHash, itemQuery),
	isCopied: copiedHash === itemHash,
	});
	const itemStyle = [styles.alignItemsCenter];
	const tooltipWrapperStyle = [styles.mh4, styles.pv2, styles.productTrainingTooltipWrapper];
	const savedSearchesMenuItems = savedSearches
	? Object.entries(savedSearches)
	.map(([key, item], index) =>
	buildSavedSearchMenuItem({
	item,
	key,
	index,
	hash,
	title: item.name === item.query ? (savedSearchTitles.get(item.query) ?? item.name) : item.name,
	getOverflowMenu,
	shouldShowSavedSearchTooltip,
	hideSavedSearchTooltip,
	renderSavedSearchTooltip,
	itemStyle,
	tooltipWrapperStyle,
	isCopied: copiedHash === Number(key),
	}),
	)
	.sort((a, b) => localeCompare(a.title ?? '', b.title ?? ''))
	: [];
	if (isVisuallyCollapsed) {
	return savedSearchesMenuItems.map((item) => (
	<SearchTypeMenuItem

Because the confirmation modal launched by showDeleteModal has no onModalHide handler that resets the row state, dismissing it by clicking outside leaves the highlighted row sticky, so the UI does not return to its previous state.

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

1. In SearchTypeMenuNarrow, clear savedSearchToModifyKey when the delete confirmation modal is hidden. Pass a reset callback into the delete flow so any dismiss path (including backdrop click) clears the active row.

App/src/pages/Search/SearchTypeMenuNarrow.tsx

Lines 79 to 158 in f36b4c5

	function SearchTypeMenuNarrow({queryJSON, onTabPress}: SearchTypeMenuNarrowProps) {
	const {isOffline} = useNetwork();
	const navigation = useNavigation();
	const {translate, localeCompare} = useLocalize();
	const {typeMenuSections, activeKey: activeTypeMenuKey} = useSearchTypeMenuSections({
	hash: queryJSON?.hash,
	similarSearchHash: queryJSON?.similarSearchHash,
	sortBy: queryJSON?.sortBy,
	sortOrder: queryJSON?.sortOrder,
	type: queryJSON?.type,
	});
	const personalDetails = usePersonalDetails();
	const feedKeysWithCards = useFeedKeysWithAssignedCards();
	const [restoreFocusType, setRestoreFocusType] = useState<BaseModalProps['restoreFocusType']>();
	const [reports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);
	const [allFeeds] = useOnyx(ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER);
	const [allPolicies] = useOnyx(ONYXKEYS.COLLECTION.POLICY);
	const [cardList] = useOnyx(ONYXKEYS.CARD_LIST);
	const [bankAccountList] = useOnyx(ONYXKEYS.BANK_ACCOUNT_LIST);
	const [workspaceCardList] = useOnyx(ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST);
	const [savedSearches] = useOnyx(ONYXKEYS.SAVED_SEARCHES);
	const isFocused = useIsFocused();
	const {counts: reportCounts} = useTodoCounts(isFocused);
	const [currentUserAccountID = -1] = useOnyx(ONYXKEYS.SESSION, {selector: accountIDSelector});
	const reportAttributes = useReportAttributes();
	const taxRates = getAllTaxRates(allPolicies);
	const cardsForSavedSearchDisplay = mergeCardListWithWorkspaceFeeds(workspaceCardList ?? CONST.EMPTY_OBJECT, cardList);
	const savedSearchTitles = useSavedSearchTitles({
	savedSearches,
	PersonalDetails: personalDetails,
	reports,
	taxRates,
	cardList: cardsForSavedSearchDisplay,
	cardFeeds: allFeeds,
	policies: allPolicies,
	currentUserAccountID,
	translate,
	feedKeysWithCards,
	reportAttributes,
	bankAccountList,
	enabled: !!queryJSON,
	});
	const [savedSearchToModifyKey, setSavedSearchToModifyKey] = useState<string | null>(null);
	const menuAnchorRef = useRef<View>(null);
	const {showDeleteModal} = useDeleteSavedSearch();
	const {copiedHash, handleShare} = useShareSavedSearch();
	const expensifyIcons = useMemoizedLazyExpensifyIcons([
	'Receipt',
	'MoneyBag',
	'CreditCard',
	'MoneyHourglass',
	'CreditCardHourglass',
	'Bank',
	'User',
	'Folder',
	'Basket',
	'CalendarSolid',
	'Bookmark',
	'Pencil',
	'Trashcan',
	'LinkCopy',
	'Checkmark',
	'Document',
	'ThumbsUp',
	'CheckCircle',
	]);
	const queryMap = new Map<string, {query: string; name?: string}>();
	const tabItems: TabSelectorBaseItem[] = [];
	const savedSearchesPopoverMenuItems: Record<string, PopoverMenuItem[]> = {};
	let activeKey = '';
	const savedSearchesTabItems: TabSelectorBaseItem[] = savedSearches
	? Object.entries(savedSearches)
	.map(([key, item]): TabSelectorBaseItem | null => {

const onDeleteModalHide = () => setSavedSearchToModifyKey(null);

Wire onDeleteModalHide into the showDeleteModal invocation so the highlight is dropped on dismiss.

2. In useDeleteSavedSearch, accept an optional onModalHide (or onClose) callback in showDeleteModal and forward it to the underlying ConfirmModal's onModalHide prop, so the hook resets the caller's active state on every close, not only on confirm/cancel. This is the central fix that both SearchTypeMenuNarrow and SavedSearchList can reuse.

3. In SavedSearchList, pass the same reset callback that clears its active/popover row when the delete modal is hidden, using the same showDeleteModal signature.

App/src/pages/Search/SavedSearchList.tsx

Lines 105 to 184 in f36b4c5

	function SavedSearchList({hash, areAllSectionsExpanded}: SavedSearchListProps) {
	const styles = useThemeStyles();
	const {translate, localeCompare} = useLocalize();
	const {shouldUseNarrowLayout} = useResponsiveLayout();
	const {isVisuallyCollapsed} = useSearchSidebarCollapse();
	const isFocused = useIsFocused();
	const [savedSearches] = useOnyx(ONYXKEYS.SAVED_SEARCHES);
	const [allPolicies] = useOnyx(ONYXKEYS.COLLECTION.POLICY);
	const personalDetails = usePersonalDetails();
	const [cardList] = useOnyx(ONYXKEYS.CARD_LIST);
	const [workspaceCardList] = useOnyx(ONYXKEYS.COLLECTION.WORKSPACE_CARDS_LIST);
	const [reports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);
	const [allFeeds] = useOnyx(ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_DOMAIN_MEMBER);
	const [bankAccountList] = useOnyx(ONYXKEYS.BANK_ACCOUNT_LIST);
	const feedKeysWithCards = useFeedKeysWithAssignedCards();
	const [currentUserAccountID = -1] = useOnyx(ONYXKEYS.SESSION, {selector: accountIDSelector});
	const reportAttributes = useReportAttributes();
	const {showDeleteModal} = useDeleteSavedSearch();
	const {
	shouldShowProductTrainingTooltip: shouldShowSavedSearchTooltip,
	renderProductTrainingTooltip: renderSavedSearchTooltip,
	hideProductTrainingTooltip: hideSavedSearchTooltip,
	} = useProductTrainingContext(CONST.PRODUCT_TRAINING_TOOLTIP_NAMES.RENAME_SAVED_SEARCH, isFocused && areAllSectionsExpanded);
	const expensifyIcons = useMemoizedLazyExpensifyIcons(['Bookmark', 'Pencil', 'Trashcan', 'LinkCopy', 'Checkmark']);
	const {copiedHash, handleShare} = useShareSavedSearch();
	const taxRates = getAllTaxRates(allPolicies);
	const cardsForSavedSearchDisplay = mergeCardListWithWorkspaceFeeds(workspaceCardList ?? CONST.EMPTY_OBJECT, cardList);
	const savedSearchTitles = useSavedSearchTitles({
	savedSearches,
	PersonalDetails: personalDetails,
	reports,
	taxRates,
	cardList: cardsForSavedSearchDisplay,
	cardFeeds: allFeeds,
	policies: allPolicies,
	currentUserAccountID,
	translate,
	feedKeysWithCards,
	reportAttributes,
	bankAccountList,
	});
	const getOverflowMenu = (itemName: string, itemHash: number, itemQuery: string) =>
	getOverflowMenuUtil(expensifyIcons, itemName, itemHash, itemQuery, translate, showDeleteModal, false, undefined, {
	onShare: () => handleShare(itemHash, itemQuery),
	isCopied: copiedHash === itemHash,
	});
	const itemStyle = [styles.alignItemsCenter];
	const tooltipWrapperStyle = [styles.mh4, styles.pv2, styles.productTrainingTooltipWrapper];
	const savedSearchesMenuItems = savedSearches
	? Object.entries(savedSearches)
	.map(([key, item], index) =>
	buildSavedSearchMenuItem({
	item,
	key,
	index,
	hash,
	title: item.name === item.query ? (savedSearchTitles.get(item.query) ?? item.name) : item.name,
	getOverflowMenu,
	shouldShowSavedSearchTooltip,
	hideSavedSearchTooltip,
	renderSavedSearchTooltip,
	itemStyle,
	tooltipWrapperStyle,
	isCopied: copiedHash === Number(key),
	}),
	)
	.sort((a, b) => localeCompare(a.title ?? '', b.title ?? ''))
	: [];
	if (isVisuallyCollapsed) {
	return savedSearchesMenuItems.map((item) => (
	<SearchTypeMenuItem

This ensures the row highlight is tied to the popover/modal lifecycle and is always cleared when the confirmation modal disappears, matching the expected behavior.

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.

[aswin-s]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-08 15:46:57 UTC.

Proposal

Problem

On web/desktop, after opening the three-dot menu of a non-selected saved search, choosing Delete, then dismissing the confirmation modal by clicking outside, that saved search row stays visually highlighted (the three-dot icon remains green and the row retains its hover/focus style). Expected: dismissing the modal should leave the row in its un-focused state.

Root Cause

The visual highlight is not driven by the focused: Number(key) === hash field on the SavedSearchMenuItem — that is hash-based and never changes during this flow. It is driven by DOM focus landing on the three-dot button inside the non-selected row.

The sequence:

1. Popover opens — ThreeDotsMenu.onThreeDotsPress calls buttonRef.current?.blur() and then showPopoverMenu(), so the button is explicitly blurred before the popover appears.
2. User selects Delete — BasePopoverMenu.selectItem (src/components/PopoverMenu/index.tsx) sees item.shouldCallAfterModalHide = true (set by getOverflowMenu in src/libs/SearchUIUtils.ts:4561) and does two things in order:
   • Calls onItemSelected?.(selectedItem, index, event) — the ThreeDotsMenu callback at src/components/ThreeDotsMenu/index.tsx:209-212 unconditionally sets restoreFocusType = CONST.MODAL.RESTORE_FOCUS_TYPE.PRESERVE then calls hidePopoverMenu(item).
   • Calls close(callback, undefined, item.shouldCloseAllModals) — the popover modal closes with RESTORE_FOCUS_TYPE.PRESERVE, which causes focus to be actively restored to buttonRef (the three-dot button).
3. AFTER the popover hides, the close callback fires showDeleteModal(hash) (src/hooks/useDeleteSavedSearch.tsx:22). The three-dot button now has DOM focus.
4. The confirmation modal opens. The browser registers the three-dot button as the element focused before the modal opened.
5. User dismisses the modal — the confirmation modal closes and restores focus to the three-dot button (its recorded prior-focused element).
6. The three-dot button inside the non-selected row has DOM focus → CSS hover/focus styling applies to the MenuItem wrapper → the entire row appears highlighted.

The root cause is ThreeDotsMenu's onItemSelected unconditionally setting RESTORE_FOCUS_TYPE.PRESERVE for every selected item, including items (like Delete) that open a subsequent modal. For those items, PRESERVE causes the button to regain focus at exactly the moment the confirm modal is about to open, making the button the confirm modal's focus-restoration target.

Fix

Single-file, two-line change — src/components/ThreeDotsMenu/index.tsx:209-212

Change the onItemSelected callback to only set RESTORE_FOCUS_TYPE.PRESERVE when the selected item does not defer its action to after modal-hide. For items with shouldCallAfterModalHide: true (i.e., items that will open a subsequent modal), clear the restoreFocusType so the popover closes without forcing focus back onto the button:

// Before
onItemSelected={(item) => {
    setRestoreFocusType(CONST.MODAL.RESTORE_FOCUS_TYPE.PRESERVE);
    hidePopoverMenu(item);
}}

// After
onItemSelected={(item) => {
    setRestoreFocusType(item.shouldCallAfterModalHide ? undefined : CONST.MODAL.RESTORE_FOCUS_TYPE.PRESERVE);
    hidePopoverMenu(item);
}}

shouldCallAfterModalHide already carries the exact semantic needed — "this action defers until after the popover hides, which means a subsequent modal will open." Using it avoids introducing a new prop and leaves PRESERVE behavior unchanged for all other menu items (rename, share, copy) that do not open modals.

Why no changes to useDeleteSavedSearch.tsx or SavedSearchItemThreeDotMenu.tsx

The proposal to add document.activeElement?.blur() in useDeleteSavedSearch on the non-confirm branch (src/hooks/useDeleteSavedSearch.tsx:29-31) and to blur buttonRef in SavedSearchItemThreeDotMenu (src/pages/Search/SavedSearchItemThreeDotMenu.tsx:29-45) are symptom-level workarounds. They paper over the problem by reactively unblurring after the button already gained focus. The ThreeDotsMenu fix above prevents the button from gaining focus in the first place, making those workarounds unnecessary. Adding them alongside the root-cause fix would only add noise.

Scope verification

• src/pages/Search/SavedSearchList.tsx — uses SavedSearchItemThreeDotMenu → ThreeDotsMenu. Fix covers this path. ✓
• src/pages/Search/SearchTypeMenuNarrow.tsx — the narrow/mobile variant owns its own PopoverMenu directly (not via ThreeDotsMenu) with the same PRESERVE pattern. Since the bug is only reproduced on desktop Chrome/Safari (where SearchTypeMenuNarrow is not rendered), this surface is out of scope for the reported issue but should be noted for completeness.
• getOverflowMenu in src/libs/SearchUIUtils.ts:4463 — has 3 callers. The delete item's shouldCallAfterModalHide: true config is the correct signal. No change needed here.

Alternatives considered

• Add a new shouldPreserveFocusOnSelect opt-in prop to PopoverMenuItem (default false): This would work but introduces unnecessary API surface. Default false means ALL existing ThreeDotsMenu items that currently receive PRESERVE would lose it unless explicitly opted in — a potential regression risk for any item that depends on PRESERVE for focus management. Using the existing shouldCallAfterModalHide field is more surgical.
• Blur in useDeleteSavedSearch on non-confirm dismiss: Correct outcome, wrong layer — it fires too late (after focus has already returned to the button and the confirm modal has already used the button as its restore target). The button would be re-blurred after the confirm modal closes, not before it opens.
• Set RESTORE_FOCUS_TYPE.NONE instead of undefined: Functionally equivalent if undefined is treated as "no restoreFocusType set"; undefined is the component's initial state and is the cleaner expression.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-08 15:55:26 UTC.

Proposal

What is the root cause of that problem?

The highlight is the row's isHovered state: MenuItem wraps every saved-search row in Hoverable and paints the hover background from it.

App/src/components/MenuItem.tsx

Lines 869 to 892 in 665e743

	<Hoverable isFocused={isFocused}>
	{(isHovered) => (
	<PressableWithSecondaryInteraction
	onPress={shouldCheckActionAllowedOnPress ? callFunctionIfActionIsAllowed(onPressAction, isAnonymousAction) : onPressAction}
	onPressIn={() => shouldBlockSelection && shouldUseNarrowLayout && canUseTouchScreen() && ControlSelection.block()}
	onPressOut={ControlSelection.unblock}
	onSecondaryInteraction={copyable && !deviceHasHoverSupport ? secondaryInteraction : onSecondaryInteraction}
	wrapperStyle={outerWrapperStyle}
	activeOpacity={!interactive ? 1 : variables.pressDimValue}
	opacityAnimationDuration={0}
	testID={pressableTestID}
	style={({pressed}) =>
	[
	containerStyle,
	combinedStyle,
	!interactive && styles.cursorDefault,
	isCompact && styles.alignItemsCenter,
	isCompact && styles.optionRowCompact,
	isCompactPopoverItem && (description ? styles.compactPopoverMenuItemBase : styles.compactPopoverMenuItem),
	!shouldRemoveBackground &&
	StyleUtils.getButtonBackgroundColorStyle(getButtonState(focused || isHovered, pressed, success, disabled, interactive), true),
	...(Array.isArray(wrapperStyle) ? wrapperStyle : [wrapperStyle]),
	shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled,
	isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,

ActiveHoverable tracks that state only through the React synthetic onMouseEnter/onMouseLeave handlers it attaches to the cloned child.

App/src/components/Hoverable/ActiveHoverable.tsx

Lines 105 to 119 in 665e743

	const child = useMemo(() => getReturnValue(children, isHovered), [children, isHovered]);
	const {onMouseEnter, onMouseLeave} = child.props as OnMouseEvents;
	return cloneElement(child, {
	ref: mergeRefs(elementRef, ref, child.props.ref),
	onMouseEnter: (e: React.MouseEvent) => {
	handleMouseEvents('enter')();
	onMouseEnter?.(e);
	},
	onMouseLeave: (e: React.MouseEvent) => {
	handleMouseEvents('leave')();
	onMouseLeave?.(e);
	},
	} as React.HTMLAttributes<HTMLElement>);

The row's three-dot menu lives inside the row's React subtree (as rightComponent), but its PopoverMenu content is portalled to the modal layer — outside the row in the DOM.

App/src/pages/Search/SavedSearchList.tsx

Lines 72 to 92 in 665e743

	const isItemFocused = Number(key) === hash;
	const baseMenuItem: SavedSearchMenuItem = createBaseSavedSearchMenuItem(item, key, index, title, isItemFocused);
	return {
	...baseMenuItem,
	role: CONST.ROLE.TAB,
	sentryLabel: CONST.SENTRY_LABEL.SEARCH.SAVED_SEARCH_MENU_ITEM,
	onPress: () => {
	setSearchContext(false);
	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: item?.query ?? '', name: item?.name}));
	},
	rightComponent: (
	<SavedSearchItemThreeDotMenu
	menuItems={getOverflowMenu(title, Number(key), item.query)}
	isDisabledItem={item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE}
	hideProductTrainingTooltip={index === 0 && shouldShowSavedSearchTooltip ? hideSavedSearchTooltip : undefined}
	shouldRenderTooltip={index === 0 && shouldShowSavedSearchTooltip}
	renderTooltipContent={renderSavedSearchTooltip}
	isCopied={isCopied}
	/>
	),

App/src/components/ThreeDotsMenu/index.tsx

Lines 203 to 220 in 665e743

	<PopoverMenu
	onClose={hidePopoverMenu}
	onModalHide={() => setRestoreFocusType(undefined)}
	isVisible={isPopupMenuVisible && !isBehindModal && isContainerFocused}
	anchorPosition={position ?? anchorPosition ?? {horizontal: 0, vertical: 0}}
	anchorAlignment={anchorAlignment}
	onItemSelected={(item) => {
	setRestoreFocusType(CONST.MODAL.RESTORE_FOCUS_TYPE.PRESERVE);
	hidePopoverMenu(item);
	}}
	menuItems={menuItems}
	withoutOverlay={!shouldOverlay}
	shouldSetModalVisibility={shouldSetModalVisibility}
	anchorRef={buttonRef}
	shouldEnableNewFocusManagement
	restoreFocusType={restoreFocusType}
	enableEdgeToEdgeBottomSafeAreaPadding
	/>

React dispatches synthetic mouse events along the React tree, not the DOM tree, so the portalled popover keeps feeding the row's synthetic hover: entering the popover delivers a synthetic mouseenter to the row (even though the row's DOM :hover is false at that point), and moving from the row into the popover delivers no synthetic mouseleave because React treats the portal as a child of the row. When a popover option is selected (Delete or Share), the popover unmounts under the pointer, and React never delivers the matching synthetic mouseleave for a removed element (react/react#19637) — so isHovered stays latched at true.

None of ActiveHoverable's other clear paths run in this flow (scroll re-sync, visibilitychange, isFocused → false), so the stale highlight persists. The trigger is the popover teardown — not the confirmation modal — which is why Share reproduces it too.

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

Track the row's hover with the native mouseenter/mouseleave events instead of the React synthetic ones, behind a new opt-in Hoverable prop. Native boundary events fire only when the pointer actually crosses the element's real DOM boundary, so the portalled popover cannot trigger the row's hover at all — there is no false enter to latch, and every real leave is delivered by the browser regardless of how the popover is dismissed (Delete, Share, Escape, click outside).

1. Add an opt-in prop shouldSubscribeToNativeMouseEvents (default false) to Hoverable/ActiveHoverable, so no other consumer changes behavior — applying the native subscription globally would be too risky.

2. In ActiveHoverable, conditionally subscribe to either the native events or the React ones. When the prop is true, attach native listeners for both mouseenter and mouseleave on elementRef and do not attach the React onMouseEnter/onMouseLeave in cloneElement (the child's own mouse-event props are left untouched). Both native handlers reuse the existing handleMouseEvents, so shouldFreezeCapture and the scroll handling stay respected.

App/src/components/Hoverable/ActiveHoverable.tsx

Lines 90 to 103 in 665e743

	const handleMouseEvents = useCallback(
	(type: 'enter' | 'leave') => () => {
	if (shouldFreezeCapture) {
	return;
	}
	const newHoverState = type === 'enter';
	isHoveredRef.current = newHoverState;
	isVisibilityHidden.current = false;
	updateIsHovered(newHoverState);
	},
	[shouldFreezeCapture, updateIsHovered],
	);

useEffect(() => {
    const element = elementRef.current;
    if (!shouldSubscribeToNativeMouseEvents || !element) {
        return;
    }
    const onNativeMouseEnter = handleMouseEvents('enter');
    const onNativeMouseLeave = handleMouseEvents('leave');
    element.addEventListener('mouseenter', onNativeMouseEnter);
    element.addEventListener('mouseleave', onNativeMouseLeave);
    return () => {
        element.removeEventListener('mouseenter', onNativeMouseEnter);
        element.removeEventListener('mouseleave', onNativeMouseLeave);
    };
}, [shouldSubscribeToNativeMouseEvents, handleMouseEvents]);

In cloneElement, the synthetic onMouseEnter/onMouseLeave wrappers are attached only when the prop is false.

3. Thread the prop through MenuItem to its Hoverable (same pattern as isFocused).

App/src/components/MenuItem.tsx

Line 869 in 665e743

<Hoverable isFocused={isFocused}>

4. Enable it only for the saved-search rows in buildSavedSearchMenuItem — it flows through MenuItemList's existing {...menuItemProps} spread.

App/src/pages/Search/SavedSearchList.tsx

Lines 75 to 78 in 665e743

	return {
	...baseMenuItem,
	role: CONST.ROLE.TAB,
	sentryLabel: CONST.SENTRY_LABEL.SEARCH.SAVED_SEARCH_MENU_ITEM,

App/src/components/MenuItemList.tsx

Lines 96 to 118 in 665e743

	menuItems.map(({key, ref, ...menuItemProps}) => (
	<OfflineWithFeedback
	key={key ?? menuItemProps.title}
	pendingAction={menuItemProps.pendingAction}
	onClose={menuItemProps.onPendingActionDismiss}
	errors={menuItemProps.error}
	shouldForceOpacity={menuItemProps.shouldForceOpacity}
	>
	<MenuItem
	key={key ?? menuItemProps.title}
	wrapperStyle={wrapperStyle}
	onSecondaryInteraction={menuItemProps.link !== undefined ? (e) => secondaryInteraction(menuItemProps.link, e) : undefined}
	shouldShowContextMenuHint={menuItemProps.shouldShowContextMenuHint ?? menuItemProps.link !== undefined}
	ref={mergeRefs(ref, popoverAnchor)}
	shouldBlockSelection={!!menuItemProps.link}
	icon={icon}
	iconWidth={iconWidth}
	iconHeight={iconHeight}
	{...menuItemProps}
	disabled={!!menuItemProps.disabled || isExecuting}
	onPress={shouldUseSingleExecution ? singleExecution(menuItemProps.onPress) : menuItemProps.onPress}
	isFocused={isFocused}
	/>

Behavior note: with native tracking, the row's hover background always mirrors the real pointer position — so while the popover is open and the pointer is over it, the row is no longer painted as hovered (today it is, via the false synthetic hover). The active saved search's route-derived focused background is untouched.

Implementation branch: main...KJ21-ENG:App:KJ21-ENG/95617-native-hover-events

Test coverage:

• Add a Hoverable test asserting that with shouldSubscribeToNativeMouseEvents, native mouseenter/mouseleave dispatched on the element toggle the hover state, and React-tree-only synthetic events (as produced by portalled children) do not.
• Manually verify on wide web layout: three-dot → Delete → dismiss the confirmation modal (click outside and Escape) → row is not highlighted; three-dot → Share → popover closes after the copied state → row is not highlighted; plain hover/unhover of the row still highlights and clears normally; narrow layout and all other menus are unchanged (prop defaults to false).

What alternative solutions did you explore? (Optional)

• Adding a native mouseleave listener on top of the existing synthetic subscription: incomplete — the row still receives the false synthetic mouseenter from the portalled popover, and a row that was never DOM-hovered gets no native mouseleave to clear it. Both boundary events must come from the same (native) source, chosen conditionally.
• Guarding the synthetic onMouseEnter with event.currentTarget.contains(event.target): filters the false enter, but the row stays subscribed to the React events, so a row that was genuinely hovered before the pointer moved into the popover still never receives its synthetic leave (React treats the portal as a child of the row) and keeps the stale highlight.
• Resetting the affected row via a render key when its popover closes (my earlier suggestion): discarded — we don't want to re-mount the row every time the popover closes.
• Subscribing to modal visibility (ONYXKEYS.MODAL): re-adds the per-instance re-renders that were deliberately removed in refactor: remove MODAL dependency from ActiveHoverable - limit rerenders #76216, and misses the Share path entirely.
• A global POPOVER_CLOSED DeviceEventEmitter event with an elementRef.current?.matches(':hover') re-check in ActiveHoverable: works, but adds a global event that wakes every mounted hoverable on each popover close and depends on popover-close timing.

[trasnake87]

Proposal

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

On web, opening a non-active saved search's 3-dot menu → Delete → dismissing the confirmation modal by clicking outside leaves that row visually highlighted as though it is the active search.

What is the root cause of that problem?

The stuck highlight is the row's hover state, not the focused (active-route) prop. MenuItem applies styles.hoveredComponentBG when isHovered && interactive && !focused (src/components/MenuItem.tsx:892). isHovered lives in ActiveHoverable (src/components/Hoverable/ActiveHoverable.tsx) and has exactly four reset paths: onMouseLeave, scroll, page-visibility-hidden, and isFocused transitioning true → false (lines 83–88, 111–118).

When the user clicks Delete, showDeleteModal → useDeleteSavedSearch.tsx:22 opens the confirmation via useConfirmModal. On desktop web this paints a full-screen overlay directly above the still-hovered row. Because the overlay appears while the pointer is stationary over the row, the browser never fires mouseleave on that row. That eliminates reset path #1. The overlay is a JS-layer modal — not a React Navigation screen — so useIsFocused() (route focus) never transitions to false. That eliminates reset path #4. Scroll and tab-blur are also not triggered. All four escape hatches miss.

MenuItemList pipes isFocused down to every row:

// src/components/MenuItemList.tsx:66,117
const isFocused = useIsFocused();
...
isFocused={isFocused}

Because isFocused stays true through the entire delete-modal lifecycle, ActiveHoverable's reset effect never fires, and isHovered remains true after dismiss — producing the stuck highlight.

This also explains the repro's specificity. Rename pushes an RHP route, which genuinely defocuses the row (reset path #4 fires cleanly). Share opens no overlay at all. Only Delete opens an alert modal over a stationary pointer, so only Delete reproduces.

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

Extend MenuItemList's isFocused computation to go false while an alert/confirm modal is visible. ThreeDotsMenu already exposes exactly this signal: willAlertModalBecomeVisible && !isPopover (src/components/ThreeDotsMenu/index.tsx:72). We can read it in MenuItemList via useOnyx:

src/components/MenuItemList.tsx:

import useOnyx from '@hooks/useOnyx';
import ONYXKEYS from '@src/ONYXKEYS';

// inside MenuItemList component
const isFocused = useIsFocused();
const [modal] = useOnyx(ONYXKEYS.MODAL);
const isAlertModalActive = !!modal?.willAlertModalBecomeVisible && !modal?.isPopover;

// line 117 — pass into each row
isFocused={isFocused && !isAlertModalActive}

willAlertModalBecomeVisible (not isVisible) is intentional: it goes true before the modal paints, which covers the pointer-stationarity window. The !isPopover guard ensures the 3-dot popover opening does not itself unhover the row. When the modal closes, willAlertModalBecomeVisible returns false, isFocused returns true, and ActiveHoverable's reset only triggers on the true → false edge — so the row stays un-highlighted until the pointer moves back over it.

The fix lives in one place and covers every MenuItemList that can appear beneath a confirmation modal, without touching ActiveHoverable itself (which is rendered by nearly every interactive element in the app and should not carry per-instance Onyx subscriptions).

---

Restoring this proposal — it was auto-flagged as a duplicate of an earlier proposal, but the analysis differs materially: Ours uses existing ONYXKEYS.MODAL willAlertModalBecomeVisible signal (single hook, minimal change); theirs requires new per-item callback plumbing and SavedSear.