[Due for payment 2026-07-06] [$250] UI is unclickable after navigating back from Spend tab with create modal open

[melvin-bot]

Bug Report

Description:
When the create modal is open on the Spend tab and the user navigates back using the browser's back button, the UI becomes unclickable/unresponsive.

Steps to Reproduce

1. Go to Home
2. Navigate to the Spend tab and tap Create
3. Press the browser back button

Expected Result

The UI should remain fully interactive after navigating back.

Actual Result

The UI is unclickable/unresponsive after navigating back.

Additional Context

Originally reported via Applause bug report.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067657900895851207
• Upwork Job ID: 2067657900895851207
• Last Price Increase: 2026-06-18

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

@melvin-bot[bot] the AutoAssignerTriage label has been deprecated. Please use Bug for issue triage. See https://stackoverflowteams.com/c/expensify/questions/14418 for more details.

[dostonbunyodov0006]

Contributor details
Your Expensify account email: dostonbunyodov0006@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0198fbc351f0b588eb

[melvin-bot]

⚠️ Invalid email. Please make sure to create an Expensify account with this email first here.

[dostonbunyodov0006]

Contributor details
Your Expensify account email: dostonbunyodov0006@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0198fbc351f0b588eb

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[ahmdshrif]

Proposal

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

On web, opening the Create menu (FAB) and then pressing the browser Back button leaves the whole app unresponsive — every click is swallowed even though the menu visually closes.

What is the root cause of that problem?

The Create menu is a Popover that is given two independent browser‑back mechanisms that both call onClose, and their history bookkeeping assumes only one is active.

1. It opens with shouldHandleNavigationBack (FABPopoverMenu L123). That makes Modal push a synthetic guard history entry on show and register its own popstate→onClose handler (Modal/index L111-L119).
2. Popover also defaults shouldCloseWhenBrowserNavigationChanged to true (Popover L34) and registers a second popstate→onClose listener (Popover L55-L74).

The guard logic is designed around a single owner of the back gesture: hideModal only pops the synthetic entry when it is still present (Modal/index L92-L109), and the internal‑popstate guard exists only to hide the Modal's own programmatic history.back() from the Popover listener (internalPopstateGuard L9-L17). On a real user Back both listeners fire for the same event, the modal is torn down twice, and the guard entry / React‑Navigation web‑history index are left one step out of sync. The BOTTOM_DOCKED Modal that Popover renders to document.body is never reconciled on the resulting route, so its overlay stays mounted and keeps intercepting every pointer event → unclickable UI. This is web/browser‑back only, which matches the popstate‑only code path.

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

Make the two mechanisms mutually exclusive. When shouldHandleNavigationBack is set, Modal already owns the back gesture, so Popover should not register its redundant popstate listener:

// Popover/index.tsx, top of the shouldCloseWhenBrowserNavigationChanged effect
if (!shouldCloseWhenBrowserNavigationChanged || props.shouldHandleNavigationBack) {
    return;
}

A single back press is then consumed once and the guard entry stays balanced. Regression‑safe: popovers that don't set shouldHandleNavigationBack keep their existing listener unchanged, so no other close path is affected.

What alternative solutions did you explore? (Optional)

• Extend the isInternalPopstateInProgress guard to also swallow the user back — incomplete: it still double‑closes and doesn't rebalance the history entry.
• Force setModalVisibility(false) on Modal unmount (BaseModal L121-L124) — masks the stuck overlay symptom without removing the duplicate handler.

[dilshodmackbook-sketch]

Proposal

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

On web, opening the Create menu on the Spend (Search) tab and pressing the browser Back button leaves the whole UI unclickable, even though the menu visually disappears.

What is the root cause of that problem?

This is not about which Create entry point is used or whether a history guard is pushed — it reproduces because of the open/close transition state machine in ReanimatedModal, which all of these popovers render through (the Spend create menu is SearchActionsBarCreateButton → PopoverMenu, portaled to document.body).

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

Lines 217 to 228 in bad195a

	<PopoverMenu
	onClose={hideCreateMenu}
	isVisible={isCreateMenuActive}
	menuItems={createMenuItems}
	onItemSelected={hideCreateMenu}
	anchorRef={createButtonRef}
	anchorPosition={createMenuPosition}
	anchorAlignment={{
	horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.RIGHT,
	vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.TOP,
	}}
	/>

App/src/components/Popover/index.tsx

Lines 84 to 98 in bad195a

	if (!fullscreen && !shouldUseNarrowLayout) {
	return createPortal(
	<Modal
	{...props}
	onClose={onCloseWithPopoverContext}
	type={CONST.MODAL.MODAL_TYPE.POPOVER}
	popoverAnchorPosition={anchorPosition}
	animationInTiming={disableAnimation ? DISABLED_ANIMATION_DURATION : animationInTiming}
	animationOutTiming={disableAnimation ? DISABLED_ANIMATION_DURATION : animationOutTiming}
	onLayout={onLayout}
	animationIn={animationIn}
	animationOut={animationOut}
	/>,
	document.body,
	);

Pressing Back closes the menu by flipping isVisible to false. But the effect that drives the transition only runs its close branch once the modal has fully finished opening (isContainerOpen && !isTransitioning):

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 122 to 142 in bad195a

	useEffect(() => {
	if (isVisible && !isContainerOpen && !isTransitioning) {
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	handleRef.current = InteractionManager.createInteractionHandle();
	transitionHandleRef.current = TransitionTracker.startTransition();
	onModalWillShow();
	// eslint-disable-next-line react-hooks/set-state-in-effect
	setIsVisibleState(true);
	setIsTransitioning(true);
	} else if (!isVisible && isContainerOpen && !isTransitioning) {
	handleRef.current = InteractionManager.createInteractionHandle();
	transitionHandleRef.current = TransitionTracker.startTransition();
	onModalWillHide();
	blurActiveElement();
	setIsVisibleState(false);
	setIsTransitioning(true);
	}
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [isVisible, isContainerOpen, isTransitioning]);

Because the create menu animates, Back is pressed while the open animation is still in flight — at that moment isTransitioning === true and isContainerOpen === false, so neither branch of the effect matches and the close is silently dropped. When the open animation later completes, the container mounts and is then immediately torn down; reanimated can drop the exit callback (Exiting.withCallback → onCloseCallBack) in that mount-then-exit race, so onCloseCallBack never fires and isTransitioning is never reset.

App/src/components/Modal/ReanimatedModal/Container/index.tsx

Lines 38 to 46 in bad195a

	const Exiting = useMemo(() => {
	const AnimationOut = new Keyframe(getModalOutAnimation(animationOut));
	return AnimationOut.duration(animationOutTiming).withCallback(() => {
	'worklet';
	scheduleOnRN(onCloseCallBack);
	});
	}, [animationOutTiming, onCloseCallBack, animationOut]);

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 162 to 179 in bad195a

	const onCloseCallBack = useCallback(() => {
	setIsTransitioning(false);
	setIsContainerOpen(false);
	if (handleRef.current) {
	InteractionManager.clearInteractionHandle(handleRef.current);
	}
	if (transitionHandleRef.current) {
	TransitionTracker.endTransition(transitionHandleRef.current);
	transitionHandleRef.current = null;
	}
	// Because on Android, the Modal's onDismiss callback does not work reliably. There's a reported issue at:
	// https://stackoverflow.com/questions/58937956/react-native-modal-ondismiss-not-invoked
	// Therefore, we manually call onModalHide() here for Android.
	if (getPlatform() === CONST.PLATFORM.ANDROID) {
	onModalHide();
	}
	}, [onModalHide]);

With isTransitioning stuck true, both modalVisibility and isBackdropMounted stay true on web, so the full-screen backdrop the modal portals into document.body stays mounted on top of the app and intercepts every click — the page looks normal but is unclickable.

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 228 to 248 in bad195a

	const isBackdropMounted = isVisibleState || ((isTransitioning || isContainerOpen !== isVisibleState) && getPlatform() === CONST.PLATFORM.WEB);
	const modalVisibility = isVisibleState || isTransitioning || isContainerOpen !== isVisibleState;
	return (
	<LayoutAnimationConfig skipExiting={getPlatform() !== CONST.PLATFORM.WEB}>
	<Modal
	transparent
	animationType="none"
	visible={modalVisibility}
	onRequestClose={onBackButtonPressHandler}
	statusBarTranslucent={statusBarTranslucent}
	testID={testID}
	onDismiss={() => {
	onDismiss?.();
	if (getPlatform() !== CONST.PLATFORM.ANDROID) {
	onModalHide();
	}
	}}
	style={modalStyle}
	{...props}
	>
	{isBackdropMounted && hasBackdrop && backdropView}

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

We should make the transition effect handle the "close requested while still opening" case so the close is never dropped. Since the modal never visually finished opening, we can finalize the close directly instead of waiting for onCloseCallBack, which prevents isTransitioning/modalVisibility/isBackdropMounted from sticking.

Add a branch to the effect here:

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 122 to 142 in bad195a

	useEffect(() => {
	if (isVisible && !isContainerOpen && !isTransitioning) {
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	handleRef.current = InteractionManager.createInteractionHandle();
	transitionHandleRef.current = TransitionTracker.startTransition();
	onModalWillShow();
	// eslint-disable-next-line react-hooks/set-state-in-effect
	setIsVisibleState(true);
	setIsTransitioning(true);
	} else if (!isVisible && isContainerOpen && !isTransitioning) {
	handleRef.current = InteractionManager.createInteractionHandle();
	transitionHandleRef.current = TransitionTracker.startTransition();
	onModalWillHide();
	blurActiveElement();
	setIsVisibleState(false);
	setIsTransitioning(true);
	}
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [isVisible, isContainerOpen, isTransitioning]);

} else if (!isVisible && isVisibleState && isTransitioning && !isContainerOpen) {
    // Close was requested while the open animation was still running. The branch above is
    // skipped (isContainerOpen is still false), so finalize the close here. Otherwise the
    // container mounts and immediately exits, reanimated can drop the exit callback, and
    // isTransitioning stays stuck true — keeping the web backdrop mounted and the UI unclickable.
    onModalWillHide();
    blurActiveElement();
    setIsVisibleState(false);
    setIsTransitioning(false);
}

Once isVisibleState and isTransitioning are both false, modalVisibility and isBackdropMounted resolve to false, the portaled Modal/backdrop unmount, and the page is interactive again. This fixes every create entry point at once (FAB and the Spend/Search create button) because they all share this modal layer.

Alternatively, we can guard the open completion instead: keep the latest requested visibility in a ref and make onOpenCallBack route into the close path when the modal has already been asked to hide, so it never settles into an "open" state it is about to leave.

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 148 to 160 in bad195a

	const onOpenCallBack = useCallback(() => {
	setIsTransitioning(false);
	setIsContainerOpen(true);
	if (handleRef.current) {
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	InteractionManager.clearInteractionHandle(handleRef.current);
	}
	if (transitionHandleRef.current) {
	TransitionTracker.endTransition(transitionHandleRef.current);
	transitionHandleRef.current = null;
	}
	onModalShow();
	}, [onModalShow]);

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

Mount ReanimatedModal with isVisible={true}, flip it to false before the open-animation callback (onOpenCallBack) fires, flush timers, and assert that modalVisibility/isBackdropMounted resolve to false (backdrop unmounted) and onModalHide is called — i.e. the modal does not stay mounted when it is closed mid-open.

What alternative solutions did you explore? (Optional)

Forcing the backdrop to drop pointerEvents whenever isVisible is false would hide the symptom, but it still leaves isTransitioning stuck and the portaled Modal mounted, so fixing the transition state machine is the correct root-cause fix.

[dostonbunyodov0006]

Proposal

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

On the Spend tab, opening Create and then pressing the browser back button leaves the whole app unclickable — every pointer event is swallowed and only a page refresh recovers it.

What is the root cause of that problem?

BaseModal already cleans up on unmount (Effect 3 calls hideModal(true) when shouldCallHideModalOnUnmount.current is set), so the missing reset is not the cause. The cause is inside hideModal, in how it decides whether to clear the global MODAL.isVisible flag:

if (areAllModalsHidden()) {
    if (shouldSetModalVisibility && !Navigation.isTopmostRouteModalScreen()) {
        setModalVisibility(false);
    }
}

Navigation.isTopmostRouteModalScreen() is read synchronously. When the modal is torn down by an in-app close, navigation state has already settled, so the read is correct. But a browser back unmounts the modal while the route transition is still in flight — at that instant the outgoing Create modal route is still reported as the topmost route, so isTopmostRouteModalScreen() returns true, the setModalVisibility(false) branch is skipped, and MODAL.isVisible stays true forever. The navigator''s full-screen Overlay keeps itself mounted with pointerEvents capturing, blocking every click.

The !isTopmostRouteModalScreen() guard itself is correct in intent — it prevents the overlay flickering off while transitioning between two modal screens. It just evaluates at the wrong moment during a browser-back teardown.

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

Keep the existing fast path, but when the guard is true during a teardown, re-check once the navigation transition settles instead of giving up. This fixes the race while fully preserving the modal->modal intent (in that case the post-settle top route is still a modal, so visibility is correctly kept):

// src/components/Modal/BaseModal.tsx — inside hideModal
 if (areAllModalsHidden()) {
-    if (shouldSetModalVisibility && !Navigation.isTopmostRouteModalScreen()) {
-        setModalVisibility(false);
-    }
+    if (shouldSetModalVisibility) {
+        if (!Navigation.isTopmostRouteModalScreen()) {
+            setModalVisibility(false);
+        } else {
+            // hideModal can run from the unmount cleanup while a route change
+            // (e.g. browser back) is still in flight, so isTopmostRouteModalScreen()
+            // can still report the outgoing modal route. Re-check once navigation
+            // settles; if no modal route remains, clear visibility so the overlay
+            // doesn''t stay mounted and block the UI.
+            const unsubscribe = navigationRef.addListener('state', () => {
+                unsubscribe();
+                if (areAllModalsHidden() && !Navigation.isTopmostRouteModalScreen()) {
+                    setModalVisibility(false);
+                }
+            });
+        }
+    }
 }

This needs import navigationRef from ''@libs/Navigation/navigationRef''; added to the imports. The one-shot listener unsubscribes itself, so there''s no leak.

What alternative solutions did you explore? (Optional)

• Always reset on unmount, dropping the isTopmostRouteModalScreen() guard — rejected: it brings back the overlay flicker when navigating directly from one modal screen to another, which the guard was added to prevent.
• Deriving overlay visibility from the live mounted-modal registry instead of the persisted MODAL.isVisible flag — the most robust long-term fix, but it''s an architectural change far larger than this bug warrants.

[melvin-bot]

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