[Due for payment 2026-06-17] Workspace - "Copy in progress..." & "All set!" modal cannot be dismissed by clicking outside

[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.0-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91368
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Create two workspaces - A and B.

1. Go to staging.new.expensify.com
2. Go to Workspaces.
3. Click 3-dot menu on Workspace A > Copy settings.
4. Select Workspace B > Next.
5. Select Categories > Next.
6. Click Copy settings.
7. Click outside "Copy in progress..." modal.
8. Click outside "All set!" modal.

Expected Result:

"Copy in progress..." and "All set!" modal can be dismissed by clicking outside the modal (similar to other similar modals in the app).

Actual Result:

"Copy in progress..." and "All set!" modal cannot be dismissed by clicking outside the modal.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7173707_1780769360473.28.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7173707

Issue Owner

Current Issue Owner: @fedirjh

[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/2c110fe731ec31a77115b37169a7af2773061815da7def2d76d3b4f911b84443

[melvin-bot]

@yuwenmemon recently merged #91368, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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]

Proposal

What is the root cause of that problem?

The progress modal's visibility is driven entirely by Onyx state (copyPolicySettings.currentStep), not by an internal isVisible flag:

const isVisible = copyInProgressStep || requestNotificationStep;

CopyPolicySettingsProgressModal.tsx:22-24

When you click outside a ConfirmModal, the backdrop press flows to the Modal's onClose handler (ConfirmModal.tsx:186), which is wired to onCancel. The base modal only falls back to onClose when no onBackdropPress is supplied (BaseModal.tsx:190-194).

For both flagged steps, onCancel is a no-op:

• "Copy in progress…" step → onCancel: () => {} (:55-60)
• "All set!" step → onCancel: () => {} (:39-43)

So clicking outside calls a no-op that never changes the Onyx step, isVisible stays true, and the modal can't be dismissed. (Only the "Notify me when it's done" Concierge step at :63-79 wires onCancel to clearCopyPolicySettings(), which is why that one can be dismissed.)

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

Wire the backdrop-dismiss handler to the appropriate state-clearing action for each step, mirroring what the buttons already do:

• "All set!" step: set onCancel to clearCopyPolicySettings() — the same action the Done button calls in onConfirm (:39-43). Dismissing the final confirmation is unambiguous.
• "Copy in progress…" step: decide the intended outcome of clicking outside while a copy is running. Cleanest option that matches the in-modal control is to mirror the "Notify me" button (requestCopyPolicySettingsNotification() + advance to the Complete step), so the copy keeps running in the background. Alternatively, if product wants outside-click to be a true cancel, call clearCopyPolicySettings().

Note: ConfirmModal already exposes a dedicated onBackdropPress prop (ConfirmModal.tsx:187) if the team wants backdrop-dismiss to differ from the buttons' onCancel.

This needs a product call on the in-progress step's behavior before implementing — the "All set!" fix is straightforward.

What alternative solutions did you explore? (Optional)

If the product intent is that these progress modals should be intentionally non-dismissible (some apps block dismissal while an operation runs), then this is working as designed and the issue should be closed as a QA expectation mismatch rather than a bug. The expected result in the report ("similar to other similar modals in the app") suggests dismissal is wanted, but that's worth confirming.

Introduced by & related issues

• Introduced by [Bulk workspace edits] Add Copy Policy Settings progress modal #91368 ("[Bulk workspace edits] Add Copy Policy Settings progress modal").
• Related tracking: [Due for payment 2026-06-16] [Bulk workspace edits] Progress modal (in-progress, notify-requested, complete states) [6] #88673 (progress modal states), [Due for payment 2026-07-23] [Bulk workspace edits] Handle async copy failure in the Copy Policy Settings progress modal #92563 (async copy failure handling in the same modal).

---

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

[carlosmiceli]

@fedirjh I see you grabbed this issue, do you think you will get a fix for it so we don't need to revert? Haven't started investigating yet.

[fedirjh]

@carlosmiceli This can be demoted since it is already under Beta. I will create a fix for it.