[Due for payment 2026-07-13] iOS - Expense - Unable to cancel payment

[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.26-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94392
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.5
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Create an expense.
4. Tap Submit, Approve and Mark as pay on the report.
5. Open the report.
6. Tap More > Cancel payment.
7. Tap Cancel payment.

Expected Result:

Payment can be canceled.

Actual Result:

Nothing happens after tapping Cancel payment.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7196908_1782937580985.ScreenRecording_07-02-2026_04-23-15_1.mp4

View all open jobs on GitHub

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

[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/3247de1a31c4fa0307d84a4b04f85c1645d1a25aa0f5daf78a9d5d436743bfda

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94392

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Issue Analysis

Regression source: Expensify/App#94392 ([Submit] Submit button with manager email prompt take 2, merged 2026-06-30 — the PR this deploy blocker is assigned to). It restructured the exact "More" menu that hosts the Cancel payment action, so the timing lines up with staging-only / not-in-production.

Root cause (medium confidence — mechanism needs one iOS device check): #94392 wrapped the entire More menu in a new <ReportSubmitToPopoverAnchor>. That anchor eagerly and permanently mounts an extra native iOS <Modal> (via useReportSubmitToPopover → PopoverWithMeasuredContent → native Popover/Modal), even when the submit-to popover is never opened — because the popover is rendered unconditionally at ReportSubmitToPopoverAnchor.tsx:276 with static non-zero dimensions.

Cancel payment confirms through the global confirm modal and only fires the API after the modal hides:

useLifecycleActions.tsx: CANCEL_PAYMENT.onSelected
  → const result = await showConfirmModal({...})   // resolves via onModalHide → closeModal({action: CONFIRM})
  → if (result.action !== ModalActions.CONFIRM) return;
  → cancelPayment(...)                              // never reached if the promise never resolves

(useLifecycleActions.tsx:357-375)

On iOS, native <Modal> stacking is fragile: with the extra always-mounted submit-to <Modal> co-existing in the RHP subtree, the confirm modal's onDismiss/onModalHide doesn't reliably fire, so the awaited promise never resolves, ModalActions.CONFIRM is never returned, and cancelPayment() is never called → "nothing happens." This is iOS-specific (Android/web resolve modal-hide through different paths), which matches the report.

Recommended fix: Since this is a deploy blocker, the safest immediate option is revert #94392. The targeted fix is to stop eagerly mounting the submit-to popover Modal: in ReportSubmitToPopoverAnchor.tsx, only render {reportSubmitToPopover} once it has actually been opened (conditional mount / lazy on first open) so the More menu no longer carries a permanent extra native <Modal>. Then verify on an iOS device that Cancel payment confirm reaches cancelPayment.

Investigation details & how to confirm

• The Cancel payment path itself was not changed by [Submit] Submit button with manager email prompt take 2 #94392 — only the surrounding tree was wrapped. The same await showConfirmModal(...) → resolve-on-hide pattern is used by other More-menu actions (Approve, etc.) at useLifecycleActions.tsx:295 and :341, so if the modal-stacking theory is right, those confirm flows may be affected on iOS too — worth spot-checking.
• PopoverWithMeasuredContent reaches the real native Popover/Modal branch immediately because useReportSubmitToPopover passes static dimensions (POPOVER_DROPDOWN_WIDTH=334, POPOVER_DROPDOWN_MAX_HEIGHT=416), so isContentMeasured starts true and the Modal mounts on first render, not on open.
• To confirm on device: reproduce on an iOS build, add a temporary log in the confirm modal's handleModalHide and after the await showConfirmModal line in CANCEL_PAYMENT.onSelected. If those never log on iOS (but do on web/Android), onModalHide not firing is confirmed. Alternative symptom (identical result) is the extra Modal's focus/pointer layer swallowing the confirm button press — a device log distinguishes the two.

Alternative explanations considered: a pure press-swallow by an overlay View (the new [styles.w100, styles.flexColumn] wrapper in MoneyReportHeader.tsx) — less likely since that View has no pointerEvents override; and a change to cancelPayment itself — ruled out, the action is unchanged.

---

Next Steps: Reply with @MelvinBot implement this to open a draft PR with the targeted fix, or @MelvinBot <feedback> to refine. Given it's a deploy blocker, reverting #94392 may be the faster call.