[Due for payment 2026-02-26] Workspace - Workspace settings does not open when clicking on workspace row

[mitarachim]

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.3.21-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-5426/folder/13177080/41237977/1193286608
Email or phone of affected tester (no customers): jjsoidjsinjdsojosdosd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Have at least two workspaces.

1. Go to staging.new.expensify.com.
2. Go to Inbox.
3. Go to Reports.
4. Go to Workspaces tab.
5. Open workspace A.
6. Go back.
7. Open workspace B.
8. Go back.
9. Repeat Step 5 to 8 until first click on the workspace row is not responsive.

Expected Result:

Workspace settings will open each time clicking on workspace row.

Actual Result:

Workspace settings does not open when clicking on workspace row.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7080939_1771374566819.6.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @stephanieelliott

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @yuwenmemon (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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #82312 - "Fix: modal race condition" by @waterim (High confidence)
Related Issues: Fixes #79732

Recommendation: REVERT

PR #82312 modified the Modal component's navigation handling by changing how popstate event listeners are managed during modal hide operations. When workspace settings are opened repeatedly (open workspace A, go back, open workspace B, go back, etc.), the modified event listener cleanup/setup logic causes navigation to become unresponsive after several cycles.

The workspace navigation uses Navigation.navigate() which triggers modal-based navigation on web. The race condition fix inadvertently introduced a new issue where rapid navigation causes event listeners to get into an inconsistent state, making subsequent clicks unresponsive.

Labels: This is a Frontend bug - keeping DeployBlockerCash, removing DeployBlocker

Detailed Analysis

Evidence

• Bug is reproducible on staging (version 9.3.21-0) but not production, matching PR Fix: modal race condition #82312's merge to staging
• Symptom appears after repeated workspace navigation (open/back cycles), which exercises the modal navigation path multiple times
• PR Fix: modal race condition #82312 specifically modified hideModal() function in /src/components/Modal/index.tsx to change event listener management

Verification

The PR modified the Modal component at:

• File: src/components/Modal/index.tsx
• Change: Modified hideModal() to remove the popstate listener first, then conditionally add a one-time listener for onModalHide before calling window.history.back()

Before PR #82312:

const hideModal = () => {
    onModalHide();
    if ((window.history.state as WindowState)?.shouldGoBack && shouldHandleNavigationBack) {
        window.history.back();
    }
};

After PR #82312:

const hideModal = () => {
    window.removeEventListener('popstate', handlePopState);
    if ((window.history.state as WindowState)?.shouldGoBack && shouldHandleNavigationBack) {
        window.addEventListener('popstate', onModalHide, {once: true});
        window.history.back();
    } else {
        onModalHide();
    }
};

Root Cause

When workspace settings are opened via Navigation.navigate(ROUTES.WORKSPACE_OVERVIEW.getRoute(policyID)) or WORKSPACE_INITIAL, the navigation system uses modals for the RHP (Right Hand Panel).

The issue occurs during rapid navigation cycles:

1. User opens workspace A → modal shows, showModal() adds popstate listener
2. User goes back → hideModal() removes listener, adds one-time listener, calls history.back()
3. User opens workspace B → modal shows, adds popstate listener again
4. User goes back → hideModal() removes listener, adds one-time listener
5. After several cycles, the event listener state becomes inconsistent
6. Subsequent workspace clicks fail to trigger navigation

The timing of when onModalHide is called (via the one-time listener) vs when the next navigation starts creates a race condition that wasn't present in the original code.