[Due for payment 2026-07-13] [$250] iOS-Expense- App freezes when pay transactions with locked account

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.25-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92518
Email or phone of affected tester (no customers): applausetester+dk12@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 11/iOS 26.5
App Component: Money Requests

Action Performed:

Preconditions:

• Account has a payable report: from 2 expenses
• Lock the account

1. Open Hybrid app
2. Open the payable report
3. Select all transactions
4. Tap on 'X selected' button
5. Select Pay > Mark as paid

Expected Result:

Test 9: the locked account modal appears immediately

Actual Result:

App freezes

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7195925_1782859559884.App_Freeze.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7195925

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072205690339825637
• Upwork Job ID: 2072205690339825637
• Last Price Increase: 2026-07-01

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/cf4e794fed9397edf763971d961c9d063658b78040f340650dee3672b1b11e74

[MelvinBot]

Issue Analysis

Root cause (high confidence): This is a regression from #92518 (merged 2026-06-29), which added bulk Pay/Approve/Submit to report selection mode. In the new bulk-pay path the locked-account modal is opened synchronously while the payment popover is still dismissing, so two native modals transition at the same instant — a classic React Native iOS deadlock that freezes the app. The single-report Pay button never freezes because it runs the same check after the popover has fully hidden.

Proposal

What is the root cause of that problem?

Tapping a payment sub-item goes through PopoverMenu.selectItem. Because bulk items are marked shouldCallAfterModalHide, this branch runs:

• PopoverMenu/index.tsx:414-421 — onItemSelected?.(...) fires synchronously (line 415), then close(...) (line 416) starts dismissing the popover <Modal>.

onItemSelected → onSubItemSelected → onSelectionModePaymentSelect, which calls shouldBlockAction() synchronously. For a locked account that immediately mounts the global locked-account ConfirmModal:

• useSelectionModePayment.ts:122-130 — if (isAccountLocked) { showLockedAccountModal(); return true; }
• useSelectionModeReportActions.ts:218-227 — the comment even states shouldBlockAction is "checked synchronously for immediate modal feedback." Only basePaymentSelect is wrapped in InteractionManager; the block-check (and thus showLockedAccountModal) is not deferred.
• MoneyReportHeaderKYCDropdown.tsx:85-97 — onSubItemSelected calls onPaymentSelect(...) directly in the synchronous path.

So the locked-account modal presents at the same moment the popover modal begins its dismiss animation → overlapping native modal transitions → freeze.

Why the single-report Pay button doesn't freeze: SettlementButton puts the identical check inside each option's own onSelected (SettlementButton/index.tsx:200-203 via checkForNecessaryAction, wired at :333). PopoverMenu runs onSelected inside the close(() => selectedItem.onSelected?.()) callback — i.e. after the popover is gone — so there is no modal overlap.

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

Make the bulk path run the locked/blocked-action check after the popover hides, matching SettlementButton. Minimal fix: in useSelectionModeReportActions.ts onSelectionModePaymentSelect, move the shouldBlockAction() call inside the existing InteractionManager.runAfterInteractions(...) callback (rather than running it synchronously before it), so showLockedAccountModal() fires only after the popover <Modal> has dismissed. This preserves "modal appears immediately" from the user's perspective while removing the overlap. The same structural issue exists on the search/desktop bulk path via MoneyReportHeaderSelectionDropdown.tsx → MoneyReportHeaderKYCDropdown and should be fixed the same way.

Alternatively (more consistent with SettlementButton), give the non-invoice payment sub-items in usePaymentOptions.ts their own onSelected that performs the block-check, and drop the synchronous onSubItemSelected payment branch.

What alternative solutions did you explore? (Optional)

Considered the delegate-no-access modal (Test 8) as an alternative trigger, but that path is the same synchronous shouldBlockAction code — the locked-account case (Test 9) is what's reported and matches the freeze mechanism. The invoice pay sub-items already set their own onSelected, so they run after modal hide and are not expected to freeze.

Investigation details & confidence

• Confidence: High — the freeze is fully traced through code: synchronous onItemSelected (PopoverMenu:415) mounting a global ConfirmModal while close() (PopoverMenu:416) dismisses the popover modal, versus the safe onSelected-via-close() timing in SettlementButton.
• Reported repro is a non-invoice payable expense report, whose payment sub-items have no onSelected and therefore route through the synchronous onSubItemSelected/onItemSelected path.
• No production logs needed — this is a deterministic UI/timing bug. An iOS device repro would only confirm the overlapping-modal freeze visually.
• Since the root cause is entirely within the App repo, no cross-repo escalation is required.

---

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

[kitvasyl]

Proposal

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

On iOS, selecting Pay > Mark as paid for multiple transactions while the account is locked freezes the app instead of displaying the locked-account modal.

What is the root cause of that problem?

In src/components/Search/SearchBulkActionsButton.tsx, the dropdown selection calls handleBulkPayItemSelected(). Its locked-account branch in src/libs/actions/Search.ts immediately calls showLockedAccountModal() while ButtonWithDropdownMenu is still dismissing its popover. Presenting the locked-account modal during that iOS modal transition causes the UI to freeze.

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

In SearchBulkActionsButton, defer the locked-account modal until the bulk-action menu has fully closed. Pass handleBulkPayItemSelected() a wrapper that records a pending locked-account modal request, then use ButtonWithDropdownMenu’s onOptionsMenuHide callback to clear that pending state and call showLockedAccountModal(). Apply this to both narrow and wide layout dropdowns.

This preserves the existing validation order in handleBulkPayItemSelected() while preventing overlapping modal transitions on iOS.

What alternative solutions did you explore? (Optional)

Adding an arbitrary timeout before showLockedAccountModal() would also avoid overlapping presentations, but tying it to onOptionsMenuHide is deterministic and does not depend on animation timing.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When all transactions of a payable report are selected and the user taps X selected → Pay → Mark as paid, the tapped payment sub-item is handled by MoneyReportHeaderKYCDropdown, whose ButtonWithDropdownMenu runs onSubItemSelected synchronously first and only closes the popover afterwards:

App/src/components/ButtonWithDropdownMenu/index.tsx

Lines 285 to 289 in 0d736c7

	onItemSelected={(selectedSubitem, index, event) => {
	onSubItemSelected?.(selectedSubitem, index, event);
	if (selectedSubitem.shouldCloseModalOnSelect !== false) {
	setIsMenuVisible(false);
	}

onSubItemSelected calls onPaymentSelect, which is the selection-mode wrapper onSelectionModePaymentSelect. That wrapper calls shouldBlockAction(iouPaymentType) synchronously, before its InteractionManager.runAfterInteractions block:

App/src/hooks/useSelectionModeReportActions.ts

Lines 211 to 221 in 0d736c7

	// Wrap payment select with InteractionManager for mobile performance
	// Note: shouldBlockAction is checked synchronously for immediate modal feedback,
	// and also inside basePaymentSelect (for the desktop path that uses it directly).
	const onSelectionModePaymentSelect = (event: KYCFlowEvent, iouPaymentType: PaymentMethodType, triggerKYCFlow: TriggerKYCFlow) => {
	if (shouldBlockAction(iouPaymentType)) {
	return;
	}
	InteractionManager.runAfterInteractions(() => {
	basePaymentSelect(event, iouPaymentType, triggerKYCFlow);
	});
	};

For a locked account shouldBlockAction immediately calls showLockedAccountModal():

App/src/hooks/useSelectionModePayment.ts

Lines 122 to 136 in 0d736c7

	const shouldBlockAction = (paymentMethodType?: PaymentMethodType) => {
	if (isDelegateAccessRestricted) {
	showDelegateNoAccessModal();
	return true;
	}
	if (isAccountLocked) {
	showLockedAccountModal();
	return true;
	}
	if (!isUserValidated && paymentMethodType !== CONST.IOU.PAYMENT_TYPE.ELSEWHERE) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.VERIFY_ACCOUNT.path));
	return true;
	}
	return false;
	};

showLockedAccountModal() mounts a global ConfirmModal:

App/src/components/LockedAccountModalProvider/index.tsx

Lines 22 to 29 in 0d736c7

	showLockedAccountModal: () => {
	showConfirmModal({
	title: translate('lockedAccount.title'),
	prompt: translate('lockedAccount.description'),
	confirmText: translate('common.buttonConfirm'),
	shouldShowCancelButton: false,
	});
	},

So the locked-account modal is presented while the payment popover (itself a native Modal) is still open — showLockedAccountModal() fires on the same synchronous tick, then setIsMenuVisible(false) runs to start closing the popover. On iOS, presenting a JS Modal while another Modal is still on screen deadlocks the native modal presentation → the app freezes. On web/Android there is no native modal-on-modal deadlock, so it does not reproduce (matches the iOS-only report).

Note this shouldBlockAction guard is a redundant one — the deferred basePaymentSelect already checks it again at its first line, and the file even documents it as redundant (added in PR #92518, commit "Add clarifying comment for redundant shouldBlockAction guard in mobile payment select"):

App/src/hooks/useSelectionModePayment.ts

Lines 272 to 275 in 0d736c7

	const onSelectionModePaymentSelect = (event: KYCFlowEvent, iouPaymentType: PaymentMethodType, triggerKYCFlow: TriggerKYCFlow) => {
	if (shouldBlockAction(iouPaymentType)) {
	return;
	}

So: locked account → payment sub-item tap → shouldBlockAction shows the locked modal synchronously before the popover closes → two stacked native modals on iOS → freeze.

For comparison, the flows that correctly show this modal from inside a popover close the popover first and only then show the locked modal in the after-close callback, e.g. WalletPage: closeModal(() => showLockedAccountModal()):

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 478 to 482 in 0d736c7

	if (isAccountLocked) {
	closeModal(() => showLockedAccountModal());
	return;
	}
	makeDefaultPaymentMethod();

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

Remove the redundant synchronous shouldBlockAction guard from the wrapper and let the check happen inside the already-existing InteractionManager.runAfterInteractions callback (via basePaymentSelect, which checks shouldBlockAction at its first line). By then the popover has finished hiding, so showLockedAccountModal() is presented on a clean stack — no modal-on-modal freeze:

-    // Wrap payment select with InteractionManager for mobile performance
-    // Note: shouldBlockAction is checked synchronously for immediate modal feedback,
-    // and also inside basePaymentSelect (for the desktop path that uses it directly).
     const onSelectionModePaymentSelect = (event: KYCFlowEvent, iouPaymentType: PaymentMethodType, triggerKYCFlow: TriggerKYCFlow) => {
-        if (shouldBlockAction(iouPaymentType)) {
-            return;
-        }
         InteractionManager.runAfterInteractions(() => {
             basePaymentSelect(event, iouPaymentType, triggerKYCFlow);
         });
     };

This is the smallest possible change (deletes the redundant guard already documented as redundant), keeps the existing locked/delegate/verify blocking intact (all three are re-checked inside basePaymentSelect), and applies to all platforms uniformly. InteractionManager.runAfterInteractions fires after the popover close animation completes, which is exactly the "close popover then show modal" ordering the working flows use.

Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Keep the synchronous guard but wrap the modal call in the popover's after-hide callback, i.e. route showLockedAccountModal() through the dropdown's onOptionsMenuHide/closeModal(() => showLockedAccountModal()) like WalletPage does. This works too, but it adds new wiring for a check that already runs (deferred) inside basePaymentSelect, so simply dropping the redundant early guard is fewer lines and lower regression risk while fixing the same root cause.

The same synchronous-guard-before-popover-close pattern also exists for the "Pay with workspace" path (onWorkspacePolicySelect → handleWorkspaceSelected's shouldBlockAction()); if desired it can be given the same deferral, but it is outside the reported repro (Mark as paid) and can be handled in the PR phase.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-01 06:30:04 UTC.

Proposal

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

On iOS, selecting all transactions on a payable report and choosing Pay > Mark as paid while the account is locked freezes the whole app, instead of showing the "locked account" modal.

What is the root cause of that problem?

The locked-account modal is presented on top of the still-open selection popover, and iOS cannot stack a second native Modal over one that is dismissing → the JS/UI thread deadlocks (freeze). This only happens when a second modal is triggered, i.e. exactly the locked-account case.

Chain:

1. In selection mode the "Pay" menu is a ButtonWithDropdownMenu. When you tap Mark as paid, PopoverMenu.selectItem runs the shouldCallAfterModalHide branch and calls the onItemSelected prop before it calls close() —

   App/src/components/PopoverMenu/index.tsx

   Lines 414 to 421 in e2e13da

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

2. That onItemSelected prop is ButtonWithDropdownMenu's handler, which synchronously forwards to onSubItemSelected —

   App/src/components/ButtonWithDropdownMenu/index.tsx

   Lines 294 to 299 in e2e13da

   	onItemSelected={(selectedSubitem, index, event) => {
   	onSubItemSelected?.(selectedSubitem, index, event);
   	if (selectedSubitem.shouldCloseModalOnSelect !== false) {
   	setIsMenuVisible(false);
   	}
   	}}

3. MoneyReportHeaderKYCDropdown forwards that to onPaymentSelect → onSelectionModePaymentSelect —

   App/src/components/MoneyReportHeaderKYCDropdown.tsx

   Lines 84 to 98 in e2e13da

   	onPress={() => {}}
   	onSubItemSelected={(item, _index, event) => {
   	if (isSecondaryActionAWorkspacePolicyOption(item)) {
   	if (onWorkspacePolicySelect) {
   	onWorkspacePolicySelect(item.workspacePolicy, triggerKYCFlow);
   	} else {
   	triggerKYCFlow({policy: item.workspacePolicy});
   	}
   	return;
   	}
   	if (!isSecondaryActionAPaymentOption(item)) {
   	return;
   	}
   	onPaymentSelect(event, item.value, triggerKYCFlow);
   	}}

4. which calls shouldBlockAction, and for a locked account immediately calls showLockedAccountModal() —

   App/src/hooks/useSelectionModePayment.ts

   Lines 122 to 137 in e2e13da

   	const shouldBlockAction = (paymentMethodType?: PaymentMethodType) => {
   	if (isDelegateAccessRestricted) {
   	showDelegateNoAccessModal();
   	return true;
   	}
   	if (isAccountLocked) {
   	showLockedAccountModal();
   	return true;
   	}
   	if (!isUserValidated && paymentMethodType !== CONST.IOU.PAYMENT_TYPE.ELSEWHERE) {
   	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.VERIFY_ACCOUNT.path));
   	return true;
   	}
   	return false;
   	};

So the ConfirmModal opens while the popover Modal is still mounted. On iOS that is the freeze; on Android/web modals stack fine — which is why only iOS: App is checked.

Structural cause: shouldCallAfterModalHide is supposed to defer the action until after the popover hides, but it only defers the item's own onSelected callback — the onItemSelected prop (used by these bulk flows) still fires before close(). The working single-report path proves it: SettlementButton runs the identical isAccountLocked → showLockedAccountModal guard inside each option's onSelected (

App/src/components/SettlementButton/index.tsx

Lines 193 to 201 in e2e13da

	const checkForNecessaryAction = useCallback(
	(paymentMethodType?: PaymentMethodType) => {
	if (isDelegateAccessRestricted) {
	showDelegateNoAccessModal();
	return true;
	}
	if (isAccountLocked) {
	showLockedAccountModal();

and #L333-L343), which PopoverMenu fires from inside close(...) after the modal hides — so it never freezes.

Every affected path (both route the guard through the synchronous onSubItemSelected):

• Report Selection toolbar → MoneyReportHeaderKYCDropdown (this report).
• Search page bulk actions → SearchBulkActionsButton passes the same locked-account guard through onSubItemSelected twice —

  App/src/components/Search/SearchBulkActionsButton.tsx

  Lines 164 to 215 in e2e13da

  	onSubItemSelected={(subItem) =>
  	handleBulkPayItemSelected({
  	item: subItem,
  	triggerKYCFlow,
  	isAccountLocked,
  	showLockedAccountModal,
  	policy: currentPolicy,
  	businessBankAccountOptions,
  	activeAdminPolicies,
  	isUserValidated,
  	isDelegateAccessRestricted,
  	showDelegateNoAccessModal,
  	confirmPayment,
  	userBillingGracePeriodEnds,
  	amountOwed,
  	ownerBillingGracePeriodEnd,
  	setPendingPaymentAdditionalData: (data) => {
  	pendingPaymentAdditionalDataRef.current = data;
  	},
  	currentUserAccountID: currentUserPersonalDetails.accountID,
  	})
  	}
  	success
  	isSplitButton={false}
  	style={[styles.w100, styles.ph5]}
  	anchorAlignment={{
  	horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.LEFT,
  	vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.BOTTOM,
  	}}
  	shouldUseModalPaddingStyle
  	sentryLabel={CONST.SENTRY_LABEL.SEARCH.NARROW_BULK_ACTIONS_DROPDOWN}
  	/>
  	</View>
  	) : (
  	<View style={[styles.flexRow, styles.alignItemsCenter, styles.gap3]}>
  	<ButtonWithDropdownMenu
  	onPress={() => null}
  	shouldAlwaysShowDropdownMenu
  	customText={selectionButtonText}
  	options={headerButtonsOptions}
  	shouldPopoverUseScrollView={popoverUseScrollView}
  	onSubItemSelected={(subItem) =>
  	handleBulkPayItemSelected({
  	item: subItem,
  	triggerKYCFlow,
  	isAccountLocked,
  	showLockedAccountModal,
  	policy: currentPolicy,
  	businessBankAccountOptions,
  	activeAdminPolicies,
  	isUserValidated,
  	isDelegateAccessRestricted,

  (same freeze when bulk-paying from Search on iOS).

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

Make shouldCallAfterModalHide honor its contract: defer the onItemSelected prop until after the popover hides, exactly like onSelected already is. In PopoverMenu.selectItem, move the onItemSelected call into the close() callback:

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

The locked-account modal then opens only after the popover is gone — no stacked iOS modals. This is the single convergence point, so it fixes both the report toolbar and the Search bulk path in one change.

Regression safety: only items already flagged shouldCallAfterModalHide change, and they already defer onSelected to after-hide — so any consumer reading state in onItemSelected already expects post-selection timing; items without the flag (the common case) are untouched.

Why the one-line fix fails: "just call showLockedAccountModal" is already there (line 128) — the guard does fire; the freeze is the timing, the modal is shown over the open popover. And relying on the existing shouldCallAfterModalHide does nothing here, because it only defers item.onSelected, while the bulk flows deliver the guard through the onItemSelected prop, which fires before close().

What alternative solutions did you explore? (Optional)

1. Localized (scoped) alternative: leave PopoverMenu untouched and instead defer the guard inside the two bulk consumers — move the isAccountLocked/showLockedAccountModal check out of onSubItemSelected and into the payment item's deferred onSelected, mirroring SettlementButton. Correct, but must be duplicated at each call site (MoneyReportHeaderKYCDropdown + both SearchBulkActionsButton sites) and misses any future onSubItemSelected consumer.
2. Spot-fix — wrap showLockedAccountModal in InteractionManager.runAfterInteractions. Rejected: it papers over the timing without fixing the structural "onItemSelected fires before close," and runAfterInteractions is not a reliable "after this modal hid" signal, so it can still race on slow devices.

[oqildev]

Proposal

What is the root cause of that problem?

This is an iOS native "modal presented on top of a dismissing modal" deadlock.

In the report view, the selection toolbar routes payment selection through useSelectionModeReportActions. When you tap Pay > Mark as paid in the popover submenu, the popover (a native Modal on iOS) starts dismissing and onSelectionModePaymentSelect fires. That wrapper checks shouldBlockAction synchronously, on purpose:

App/src/hooks/useSelectionModeReportActions.ts

Lines 217 to 227 in e2e13da

	// Wrap payment select with InteractionManager for mobile performance
	// Note: shouldBlockAction is checked synchronously for immediate modal feedback,
	// and also inside basePaymentSelect (for the desktop path that uses it directly).
	const onSelectionModePaymentSelect = (event: KYCFlowEvent, iouPaymentType: PaymentMethodType, triggerKYCFlow: TriggerKYCFlow) => {
	if (shouldBlockAction(iouPaymentType)) {
	return;
	}
	InteractionManager.runAfterInteractions(() => {
	basePaymentSelect(event, iouPaymentType, triggerKYCFlow);
	});
	};

For a locked account, shouldBlockAction immediately calls showLockedAccountModal():

App/src/hooks/useSelectionModePayment.ts

Lines 122 to 136 in e2e13da

	const shouldBlockAction = (paymentMethodType?: PaymentMethodType) => {
	if (isDelegateAccessRestricted) {
	showDelegateNoAccessModal();
	return true;
	}
	if (isAccountLocked) {
	showLockedAccountModal();
	return true;
	}
	if (!isUserValidated && paymentMethodType !== CONST.IOU.PAYMENT_TYPE.ELSEWHERE) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.VERIFY_ACCOUNT.path));
	return true;
	}
	return false;
	};

…and showLockedAccountModal is just a showConfirmModal(), i.e. it mounts another modal:

App/src/components/LockedAccountModalProvider/index.tsx

Lines 22 to 30 in e2e13da

	showLockedAccountModal: () => {
	showConfirmModal({
	title: translate('lockedAccount.title'),
	prompt: translate('lockedAccount.description'),
	confirmText: translate('common.buttonConfirm'),
	shouldShowCancelButton: false,
	});
	},
	};

So the locked-account confirm modal tries to present while the payment popover modal is still animating out. On iOS you cannot present a new modal over a view controller that is mid-dismiss — the presentation never completes and the JS/UI thread hangs, which is the "freeze."

The whole reason the actual payment call basePaymentSelect is already wrapped in InteractionManager.runAfterInteractions (line 224) is to wait for that popover dismissal before doing navigation/modal work. The block check was deliberately pulled out of that deferral "for immediate modal feedback," and that's exactly what reintroduces the freeze for the locked (and delegate/verify) cases. It's iOS-only because Android/web can stack these modals.

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

Defer the block check so the locked-account modal is only presented after the popover has finished dismissing. In useSelectionModeReportActions.onSelectionModePaymentSelect (lines 220-227), move the shouldBlockAction(iouPaymentType) early-return inside the InteractionManager.runAfterInteractions callback instead of running it synchronously.

basePaymentSelect (the base onSelectionModePaymentSelect from useSelectionModePayment) already calls shouldBlockAction itself at

App/src/hooks/useSelectionModePayment.ts

Lines 272 to 297 in e2e13da

	const onSelectionModePaymentSelect = (event: KYCFlowEvent, iouPaymentType: PaymentMethodType, triggerKYCFlow: TriggerKYCFlow) => {
	if (shouldBlockAction(iouPaymentType)) {
	return;
	}
	selectPaymentType({
	event,
	iouPaymentType,
	triggerKYCFlow,
	policy,
	onPress: confirmPayment,
	currentAccountID: accountID,
	currentEmail: email ?? '',
	hasViolations,
	isASAPSubmitBetaEnabled,
	isUserValidated,
	confirmApproval,
	iouReport: moneyRequestReport,
	iouReportNextStep: nextStep,
	betas,
	userBillingGracePeriodEnds,
	amountOwed,
	ownerBillingGracePeriodEnd,
	delegateEmail,
	expenseReportPolicy: policy,
	});
	};

, so the simplest correct fix is to drop the redundant synchronous check in the wrapper and let the deferred inner check present the modal. Net effect: payment is still blocked when the account is locked, and the locked modal now appears cleanly once the popover is gone (matching the expected "modal appears immediately" behavior, minus the freeze).

This is a timing/hook-layer fix, not a data or render fix — the state (isAccountLocked) is already correct; only the moment of modal presentation is wrong.

One thing to double-check while implementing: the header variant MoneyReportHeaderSelectionDropdown passes useSelectionModePayment's base onSelectionModePaymentSelect directly (

App/src/components/MoneyReportHeaderActions/MoneyReportHeaderSelectionDropdown.tsx

Lines 181 to 204 in e2e13da

	const {shouldBlockAction, onSelectionModePaymentSelect, selectionModeKYCSuccess, paymentSubMenuItems, hasPayInSelectionMode, kycWallRef} = useSelectionModePayment({
	reportID,
	transactions,
	formattedAmount: totalAmount,
	shouldHidePaymentOptions: !isPayable,
	onlyShowPayElsewhere,
	hasPayAction,
	allExpensesSelected,
	onHoldMenuOpen: ({requestType, paymentType, methodID}) => {
	openHoldMenu({
	requestType,
	paymentType,
	methodID,
	onConfirm: () => clearSelectedTransactions(true),
	});
	},
	onPaymentComplete: () => {
	clearSelectedTransactions(true);
	},
	onPaid: () => {
	startAnimation();
	},
	confirmApproval: () => confirmApproval(),
	});

), which also calls shouldBlockAction synchronously and can hit the same freeze on iOS. Deferring the modal presentation at the shouldBlockAction/showLockedAccountModal boundary would cover both entry points.

What alternative solutions did you explore? (Optional)

Defer the presentation inside showLockedAccountModal/useConfirmModal itself (wrap showConfirmModal in InteractionManager.runAfterInteractions). Rejected: that hook is shared by many unrelated confirm modals that aren't opened from a dismissing popover, so it would add latency everywhere and mask the real cause instead of fixing the specific popover→modal handoff.

Gate the deferral behind getPlatform() === CONST.PLATFORM.IOS (mirroring the existing platform-specific branch in onHoldMenuOpen, lines 200-209). Rejected as unnecessary — InteractionManager.runAfterInteractions resolves promptly on Android/web, so a single cross-platform deferral keeps the code simpler without a behavioral downside.

[dilshodmackbook-sketch]

Proposal

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

On iOS, selecting all transactions in a payable report → X selected → Pay → Mark as paid on a locked account freezes the entire app instead of showing the locked-account modal.

What is the root cause of that problem?

In the report selection mode, the payment sub-items are rendered by MoneyReportHeaderKYCDropdown, whose onSubItemSelected is wired straight into PopoverMenu's onItemSelected:

App/src/components/MoneyReportHeaderKYCDropdown.tsx

Lines 85 to 98 in a97126c

	onSubItemSelected={(item, _index, event) => {
	if (isSecondaryActionAWorkspacePolicyOption(item)) {
	if (onWorkspacePolicySelect) {
	onWorkspacePolicySelect(item.workspacePolicy, triggerKYCFlow);
	} else {
	triggerKYCFlow({policy: item.workspacePolicy});
	}
	return;
	}
	if (!isSecondaryActionAPaymentOption(item)) {
	return;
	}
	onPaymentSelect(event, item.value, triggerKYCFlow);
	}}

For a leaf sub-item flagged shouldCallAfterModalHide, PopoverMenu.selectItem calls onItemSelected synchronously, before the popover is closed — only the item's own onSelected is deferred to after the modal hides:

App/src/components/PopoverMenu/index.tsx

Lines 414 to 422 in a97126c

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

So onSubItemSelected → onPaymentSelect → onSelectionModePaymentSelect → shouldBlockAction runs while the payment popover is still mounted, and it shows the locked-account ConfirmModal immediately:

App/src/hooks/useSelectionModePayment.ts

Lines 122 to 136 in a97126c

	const shouldBlockAction = (paymentMethodType?: PaymentMethodType) => {
	if (isDelegateAccessRestricted) {
	showDelegateNoAccessModal();
	return true;
	}
	if (isAccountLocked) {
	showLockedAccountModal();
	return true;
	}
	if (!isUserValidated && paymentMethodType !== CONST.IOU.PAYMENT_TYPE.ELSEWHERE) {
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.VERIFY_ACCOUNT.path));
	return true;
	}
	return false;
	};

On iOS this mounts a second native modal on top of the still-open popover modal. Two overlapping RN modals deadlock the presentation and the app freezes.

For comparison, SettlementButton runs the exact same guard from each payment option's deferred onSelected (which fires only after the popover has hidden), so it never overlaps modals and works fine:

App/src/components/SettlementButton/index.tsx

Lines 333 to 344 in a97126c

	onSelected: () => {
	if (checkForNecessaryAction(CONST.IOU.PAYMENT_TYPE.VBBA)) {
	return;
	}
	onPress({
	paymentType: CONST.IOU.PAYMENT_TYPE.VBBA,
	payAsBusiness: true,
	methodID: account.methodID,
	paymentMethod: CONST.PAYMENT_METHODS.BUSINESS_BANK_ACCOUNT,
	});
	},
	});

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

Defer the guard modals in shouldBlockAction so they mount only after the payment popover finishes dismissing, while still blocking the payment synchronously. In src/hooks/useSelectionModePayment.ts:

import {InteractionManager} from 'react-native';

const shouldBlockAction = (paymentMethodType?: PaymentMethodType) => {
    if (isDelegateAccessRestricted) {
        InteractionManager.runAfterInteractions(() => showDelegateNoAccessModal());
        return true;
    }
    if (isAccountLocked) {
        InteractionManager.runAfterInteractions(() => showLockedAccountModal());
        return true;
    }
    if (!isUserValidated && paymentMethodType !== CONST.IOU.PAYMENT_TYPE.ELSEWHERE) {
        Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.VERIFY_ACCOUNT.path));
        return true;
    }
    return false;
};

shouldBlockAction still returns true immediately so the payment is stopped, but the ConfirmModal is presented after the popover's dismiss interaction completes — only one native modal is ever on screen at a time. The VERIFY_ACCOUNT branch is a navigation, not a modal, so it doesn't need deferring.

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

• With a locked account, invoking shouldBlockAction from the selection-mode pay flow returns true and schedules showLockedAccountModal via InteractionManager.runAfterInteractions (assert the modal is shown after interactions flush, not synchronously).
• Same assertion for the delegate-restricted branch (showDelegateNoAccessModal).
• Non-blocking case (unlocked, validated) returns false and shows no modal.

What alternative solutions did you explore? (Optional)

Restructure MoneyReportHeaderKYCDropdown so each payment sub-item carries its guard in the deferred onSelected callback (the pattern SettlementButton already uses) instead of the synchronous onSubItemSelected. This is the more structural fix but larger, since the sub-items need triggerKYCFlow/event threaded from the KYCWall render prop into each item. Another option is to flush a pending guard action from the popover's onOptionsMenuHide, but that adds ref-plumbing for the same effect the deferred call achieves directly.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-01 06:42:56 UTC.

Proposal

What is the root cause of that problem?

The selected-expense pay menu is trying to show the locked-account modal from inside the dropdown item-selection callback, before the dropdown/submenu has actually finished closing.

ButtonWithDropdownMenu marks dropdown items and subitems with shouldCallAfterModalHide, but its PopoverMenu.onItemSelected handler still invokes the consumer callback (onSubItemSelected) before it hides the menu. PopoverMenu also calls onItemSelected before the delayed close() callback runs for shouldCallAfterModalHide items, so subitem consumers can run too early.

App/src/components/ButtonWithDropdownMenu/index.tsx

Lines 294 to 328 in a97126c

	onItemSelected={(selectedSubitem, index, event) => {
	onSubItemSelected?.(selectedSubitem, index, event);
	if (selectedSubitem.shouldCloseModalOnSelect !== false) {
	setIsMenuVisible(false);
	}
	}}
	anchorPosition={popoverAnchorPosition}
	shouldShowRadioButton={shouldShowRadioButton}
	anchorRef={nullCheckRef(dropdownAnchor)}
	scrollContainerStyle={!shouldUseModalPaddingStyle && isSmallScreenWidth && {...styles.pt4, paddingBottom}}
	anchorAlignment={anchorAlignment}
	shouldUseModalPaddingStyle={shouldUseModalPaddingStyle}
	headerText={menuHeaderText}
	shouldUseScrollView={shouldPopoverUseScrollView}
	containerStyles={containerStyles}
	menuItems={options.map((item, index) => ({
	...item,
	onSelected: item.onSelected
	? () => {
	item.onSelected?.();
	if (item.shouldUpdateSelectedIndex) {
	setSelectedItemIndex(index);
	}
	}
	: () => {
	onOptionSelected?.(item);
	if (item.shouldUpdateSelectedIndex === false) {
	return;
	}
	setSelectedItemIndex(index);
	},
	shouldCallAfterModalHide: true,
	subMenuItems: item.subMenuItems?.map((subItem) => ({...subItem, shouldCallAfterModalHide: true})),
	}))}

App/src/components/PopoverMenu/index.tsx

Lines 414 to 422 in a97126c

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

In this selected-expense payment flow, that early subitem callback calls onSelectionModePaymentSelect. On mobile it immediately runs shouldBlockAction(), and locked accounts make that guard call showLockedAccountModal(). That opens a second modal while the pay dropdown is still closing, which matches the iOS freeze/splash behavior instead of the locked-account modal appearing cleanly.

App/src/hooks/useSelectionModeReportActions.ts

Lines 217 to 226 in a97126c

	// Wrap payment select with InteractionManager for mobile performance
	// Note: shouldBlockAction is checked synchronously for immediate modal feedback,
	// and also inside basePaymentSelect (for the desktop path that uses it directly).
	const onSelectionModePaymentSelect = (event: KYCFlowEvent, iouPaymentType: PaymentMethodType, triggerKYCFlow: TriggerKYCFlow) => {
	if (shouldBlockAction(iouPaymentType)) {
	return;
	}
	InteractionManager.runAfterInteractions(() => {
	basePaymentSelect(event, iouPaymentType, triggerKYCFlow);
	});

App/src/hooks/useSelectionModePayment.ts

Lines 122 to 130 in a97126c

	const shouldBlockAction = (paymentMethodType?: PaymentMethodType) => {
	if (isDelegateAccessRestricted) {
	showDelegateNoAccessModal();
	return true;
	}
	if (isAccountLocked) {
	showLockedAccountModal();
	return true;
	}

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

Make ButtonWithDropdownMenu honor shouldCallAfterModalHide for the callbacks it owns. When mapping root items and submenu items for PopoverMenu, attach delayed onSelected handlers that invoke onOptionSelected/onSubItemSelected after PopoverMenu.close() completes, and let onItemSelected only update local dropdown state such as the selected index and visible flag.

For submenu items, preserve any existing subItem.onSelected behavior, but run it from the same delayed wrapper as onSubItemSelected so payment subitems do not execute once before close and again after close. This keeps the locked-account guard in the shared payment hook, but ensures showLockedAccountModal() runs only after the payment dropdown has been dismissed.

App/src/components/ButtonWithDropdownMenu/index.tsx

Lines 294 to 328 in a97126c

	onItemSelected={(selectedSubitem, index, event) => {
	onSubItemSelected?.(selectedSubitem, index, event);
	if (selectedSubitem.shouldCloseModalOnSelect !== false) {
	setIsMenuVisible(false);
	}
	}}
	anchorPosition={popoverAnchorPosition}
	shouldShowRadioButton={shouldShowRadioButton}
	anchorRef={nullCheckRef(dropdownAnchor)}
	scrollContainerStyle={!shouldUseModalPaddingStyle && isSmallScreenWidth && {...styles.pt4, paddingBottom}}
	anchorAlignment={anchorAlignment}
	shouldUseModalPaddingStyle={shouldUseModalPaddingStyle}
	headerText={menuHeaderText}
	shouldUseScrollView={shouldPopoverUseScrollView}
	containerStyles={containerStyles}
	menuItems={options.map((item, index) => ({
	...item,
	onSelected: item.onSelected
	? () => {
	item.onSelected?.();
	if (item.shouldUpdateSelectedIndex) {
	setSelectedItemIndex(index);
	}
	}
	: () => {
	onOptionSelected?.(item);
	if (item.shouldUpdateSelectedIndex === false) {
	return;
	}
	setSelectedItemIndex(index);
	},
	shouldCallAfterModalHide: true,
	subMenuItems: item.subMenuItems?.map((subItem) => ({...subItem, shouldCallAfterModalHide: true})),
	}))}

Test coverage:

• Add or update a ButtonWithDropdownMenu/PopoverMenu unit test proving a submenu item's consumer callback is not called until after the close callback when shouldCallAfterModalHide is true.
• Manually verify on iOS native/hybrid that selecting all payable expenses and choosing Pay > Mark as paid on a locked account closes the dropdown and then shows the locked-account modal without freezing.
• Regression-check that an unlocked account can still use Pay > Mark as paid from the same selected-expense dropdown.

What alternative solutions did you explore? (Optional)

We could special-case locked accounts in useSelectionModeReportActions or useSelectionModePayment with another InteractionManager.runAfterInteractions() deferral, but that only patches this payment path and leaves ButtonWithDropdownMenu continuing to advertise delayed execution while onSubItemSelected bypasses it.

[melvin-bot]

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