Workspace -Browser back button with "All Set" modal open leads to previous page on background

[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+ib0005@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Prerequisite: Use expensifail account.
Prerequisite 2: User is admin of at least two control workspaces.

1. Open the staging.new.expensify.com website.
2. Navigate to "Inbox"
3. Navigate to "Workspaces"
4. Click on the three dots icon on any workspace > "Copy Settings"
5. Select any workspace > "Next"
6. Select some settings > "Next" > "Copy Settings"
7. Wait until "Copy in progress" modal disappears.
8. When "All Set" modal appears, click on browser´s back button.
9. Note that "All Set" modal is still displayed and website returns to previous page on the background.

Expected Result:

Using browser´s back button while "All Set" modal is displayed, should only close the modal.

Actual Result:

User is redirected to previous page on the background, with "All Set" modal still displayed, after using browser´s back button.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7173133_1780711715319.All_Set.mp4

View all open jobs on GitHub

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

[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/269516143a42a78c610d90a2c259967fa9c78229de5e5e6831f951bef73c82af

[melvin-bot]

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

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

[godzillaxbox19982014-lgtm]

Proposal

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

Workspace -Browser back button with "All Set" modal open leads to previous page on background

What is the root cause of that problem?

I traced this to the path that handles workspace name:

• src/pages/workspace/copyPolicySettings/CopyPolicySettingsSelectFeaturesPage.tsx:277 (matching code path): onBackButtonPress={Navigation.goBack}
• src/pages/workspace/WorkspacePageWithSections.tsx:270 (matching code path): style={[styles.settingsPageBackground, styles.flex1, styles.w100]}
• src/pages/workspace/copyPolicySettings/CopyPolicySettingsSelectWorkspacesPage.tsx:156 (matching code path): onBackButtonPress={Navigation.goBack}
• The local evidence matches this recurring failure shape: route params are created in one format and read in another. Here, src/pages/workspace/copyPolicySettings/CopyPolicySettingsSelectFeaturesPage.tsx:277 and src/pages/workspace/WorkspacePageWithSections.tsx:270 do not agree on the same workspace name value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/workspace/copyPolicySettings/CopyPolicySettingsSelectFeaturesPage.tsx:277 to derive workspace name from the route/access source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/WorkspacePageWithSections.tsx:270; that follows the safer family move to fix the route builder/consumer pair instead of adding a screen-only redirect, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Navigation, RHP, Not Here, Back Stack surface and avoid changing deep links, auth/onboarding redirects.

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

1. Add or update a regression in tests/navigation/**/*.ts for the exact issue flow: Workspace -Browser back button with "All Set" modal open leads to previous page on background.
2. Cover the counter-case near src/pages/workspace/copyPolicySettings/CopyPolicySettingsSelectFeaturesPage.tsx:277 so valid existing workspace name behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name consistent at the first read/write boundary shown above.

[MelvinBot]

Proposal

What is the root cause of that problem?

The "All Set" / progress modal is a ConfirmModal whose visibility is driven purely by Onyx state (copyPolicySettings.currentStep), not by a navigation route.

It is rendered without the shouldHandleNavigationBack prop. On web, that prop is what makes a modal intercept the browser back button — when it is set, the web Modal pushes a shouldGoBack history guard entry and registers a popstate listener on show, so back press is caught and routed to onClose instead of navigating.

Because this prop is missing, no guard entry/listener is registered, so the browser back button is handled by React Navigation and pops the underlying screen. The page navigates back in the background, while the modal stays on screen because its visibility depends on Onyx state, not the route. That is exactly the reported symptom.

This regressed in #91368.

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

In CopyPolicySettingsProgressModal.tsx:

1. Pass shouldHandleNavigationBack to the <ConfirmModal>. This makes the back press get intercepted by the modal and prevents the background screen from navigating away.
2. Make the back press actually dismiss the "All Set" modal. The modal's back handler calls onCancel, but the All Set step's onCancel is currently a no-op. Point it at clearCopyPolicySettings() (same as the "Done" button's onConfirm) so back press closes the modal — matching the expected result. Consider the same for the loading step depending on desired behavior there.

Why this matches the expected result

Expected: "Using browser's back button while 'All Set' modal is displayed, should only close the modal."

• shouldHandleNavigationBack → back press is consumed by the modal's popstate guard, so the underlying page does not navigate (fixes "redirected to previous page on background").
• onCancel: clearCopyPolicySettings → clearCopyPolicySettings() resets the Onyx key, making currentStep undefined and isVisible false, so the modal closes.

Without step 2, enabling shouldHandleNavigationBack alone would stop the background navigation but the modal would stay open (no-op onCancel).

What alternative solutions did you explore? (Optional)

Tying the modal to a dedicated route so back navigation closes it naturally. This is a larger change and unnecessary given the existing shouldHandleNavigationBack mechanism already used elsewhere for state-driven modals.

Confidence: High — code evidence is clear and the fix is entirely within the App repo (web frontend).

---

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