[Due for payment 2026-04-16] IOS - Copilot - App becomes unresponsive when trying to change the Copilot access

[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: v9.3.37-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-8762/folder/13176687/41236698/1247680797?sort=%2Bidentifier&p=2
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: iPhone 13 iOS 26.3
App Component: User Settings

Action Performed:

Preconditions: account set a copilot.

1. Open the app
2. Go to Account > Security > Copilot
3. Tap the 3-dot menu near the copilot
   4.Tap Change access level

Expected Result:

The user should be able to change Copilot access or tap the back button, and the app should remain responsive

Actual Result:

App gets unresponsive when trying to change copilot access

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7101754_1773369710273.ScreenRecording_03-12-2026_21-33-01_1.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @aldo-expensify (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: #82764 - "Freeze non top screens to prevent extra-rerenders" by @VickyStash (High confidence)
Related Issues: #85184 (another deploy blocker with similar "app freezes" symptoms)

Recommendation: REVERT

PR #82764 introduced screen freezing logic to prevent unnecessary re-renders on non-visible screens. However, this appears to be causing app unresponsiveness when navigating to certain modal screens, including the Copilot "Change access level" page.

Labels: Removed DeployBlocker (backend label) because this is a frontend bug requiring an App PR revert/fix. Kept DeployBlockerCash because this blocks the App deploy and is staging-only (not reproducible on production).

Detailed Analysis

Evidence

PR #82764 was merged on 2026-03-12 and is included in the current staging deploy (v9.3.37-0). The PR introduces screen freezing functionality via:

1. A new ScreenFreezeWrapper component that uses react-freeze to freeze non-visible screens
2. React Navigation patches that freeze screens below the focused screen
3. Enabling enableFreeze(true) from react-native-screens on mobile

The timing aligns perfectly:

• PR merged: 2026-03-12 at 14:05:57 UTC
• Issue reported: 2026-03-13 at 06:15:31 UTC (affects v9.3.37-0)
• Issue is staging-only (not in production)

Verification

The UpdateDelegateRolePage (the "Change access level" screen for Copilots) is part of the Settings RHP (Right Hand Panel) navigator, which uses the SplitNavigator that was modified by PR #82764 to apply screen freezing.

From the PR diff:

// src/libs/Navigation/AppNavigator/createSplitNavigator/index.tsx
const SplitNavigatorComponent = createPlatformStackNavigatorComponent("SplitNavigator", {
    // ...
    freezeNonTopScreens: true,  // <- Added by PR #82764
});

When a user navigates from the Security > Copilot screen to the "Change access level" modal, the screen freezing logic may incorrectly freeze the target screen or interfere with the navigation transition, causing the app to become unresponsive.

Root Cause

The screen freezing implementation in PR #82764 appears to have edge cases that cause navigation to modal screens (like the UpdateDelegateRolePage) to fail or become unresponsive. The ScreenFreezeWrapper and related patches that freeze screens "below the focused one" may be incorrectly determining which screen should be frozen during navigation transitions, particularly for modal presentations.

Additional evidence:

• Issue [Due for payment 2026-04-16] Web-Ecard-App freezes when clicking on the Go to Expensify cards button #85184 reports similar "app freezes" symptoms when clicking "Go to Expensify Cards" button (also a navigation action)
• The PR explicitly modified navigation freeze behavior and added requestAnimationFrame timing logic that could cause race conditions
• The issue only affects iOS App (mobile), where enableFreeze(true) is called, consistent with the PR changes

[MelvinBot]

Proposal

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

The iOS app becomes unresponsive when tapping "Change access level" from the 3-dot menu on a copilot in Account > Security > Copilot. This reproduces in staging (v9.3.37-0) but not in production.

What is the root cause of that problem?

There are two interacting causes:

1. Pre-existing bug: onPress bypasses PopoverMenu's modal-close sequencing

In SecuritySettingsPage.tsx:343-361, the "Change access level" popover menu item uses onPress instead of onSelected:

onPress: () => {
    Navigation.navigate(ROUTES.SETTINGS_UPDATE_DELEGATE_ROLE.getRoute(...));
    setShouldShowDelegatePopoverMenu(false);  // closes modal AFTER navigating
}

In PopoverMenu.tsx:388-436, onPress is NOT destructured out of the menu item props (line 388-398). It stays in menuItemProps and gets spread ({...menuItemProps} on line 436) AFTER the explicit onPress={(event) => selectItem(menuIndex, event)} on line 412, overriding the selectItem handler entirely. This means PopoverMenu's modal-closing logic (shouldCallAfterModalHide, close()) is completely bypassed.

The result: Navigation.navigate() fires while the iOS popover modal (rendered as a BOTTOM_DOCKED Modal via a separate UIWindow) is still visible.

Compare with the "Remove copilot" item on line 376 which correctly uses modalClose(() => { ... }) to close the modal first.

2. New in staging: PR #82764 introduced screen freezing on Fabric/iOS

This PR enabled enableFreeze(true) globally in setup/index.ts and patched @react-navigation/native-stack to remove the isBelowFocused safety exception on Fabric. Previously on iOS (Fabric), the screen directly below the focused screen was excluded from freezing. Now it gets frozen via react-freeze's Suspense mechanism (throws a never-resolving Promise).

When navigation happens while the modal is still open:

1. The new screen is pushed (UpdateDelegateRolePage)
2. The underlying SecuritySettingsPage screen gets frozen via Suspense
3. The Suspense-based freeze blocks React's rendering pipeline (a startTransition fix for this was reverted in commit cfe0d141cb1)
4. The modal close animation can't complete because React rendering is blocked
5. The app becomes permanently unresponsive

In production, without screen freezing, the navigation-while-modal-open conflict was tolerable. In staging, the new freeze mechanism turns it into a permanent lockup.

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

In src/pages/settings/Security/SecuritySettingsPage.tsx, change the "Change access level" menu item from using onPress to using onSelected with shouldCallAfterModalHide: true:

• Replace onPress with onSelected on the "Change access level" item
• Add shouldCallAfterModalHide: true to the item
• The onSelected callback should contain the navigation and state cleanup logic

This matches the established pattern used throughout the codebase (e.g., src/hooks/useSearchTypeMenu.tsx:213-217). It ensures the popover modal closes first, and only after the close animation completes does the navigation callback fire via onModalDidClose().

The same fix should also be applied to the early returns in the "Change access level" handler (the isActingAsDelegate and isAccountLocked branches at lines 349-356 already correctly use modalClose()).

What alternative solutions did you explore? (Optional)

An alternative would be to wrap the navigation call in modalClose() (similar to the "Remove copilot" handler). However, using onSelected + shouldCallAfterModalHide is the more correct approach because it works through PopoverMenu's built-in selectItem mechanism rather than bypassing it, and is consistent with how other popover menu items that navigate are implemented across the codebase.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.