Workspace settings do not open immediately after creation, ESC key not working

[jponikarchuk]

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.62-5
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85234
Email or phone of affected tester (no customers): sdsodijnosdjoij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Workspace Settings

Action Performed:

1 .Go to staging.new.expensify.com
2. Go to Workspaces tab.
3. Create a new workspace.
BUG 1: Workspace settings open after some delay.
4. Press ESC key.
BUG 2: App does not return to workspace settings after pressing ESC key.

Expected Result:

BUG 1: Workspace settings will open immediately after creating workspace.
BUG 2: App will return to workspace settings after pressing ESC key.

Actual Result:

BUG 1: Workspace settings open after some delay.
BUG 2: App does not return to workspace settings after pressing ESC key.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @sumo-slonik

[melvin-bot]

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

[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: #85234 - "Introduce a Bottom Tab Navigator for Top-Level Navigation" by @WojtekBoman (High confidence)
Related Issues: None

Recommendation: REVERT

PR #85234 introduced a fundamental restructuring of the top-level navigation tree (adding a TabNavigator wrapping all full-screen navigators). The two reported bugs are both direct consequences of that navigation refactor affecting the Workspace tab flow.

Assigned: @WojtekBoman (PR author), @ZhenjaHorbach (approving reviewer), @mountiny (approving reviewer)
Labels: DeployBlockerCash kept (Frontend bug — App PR caused the issue). No label changes made.

📋 Detailed Analysis

Evidence

Bug 1 — Workspace settings open after a delay after creating a workspace:
PR #85234 changed all top-level full-screen navigators (including WORKSPACE_NAVIGATOR) from being registered as direct root stack screens to being tab screens inside a new TAB_NAVIGATOR. It also removed usePreloadFullScreenNavigators from WorkspaceNavigator. The tab navigator needs to initialise the workspace tab screen lazily when first navigated to (unlike the previous approach where the navigator was always pushed onto the root stack). After a workspace is created the user is navigated into the workspace settings screen, and the new tab-based initialisation path introduces a visible delay before the workspace settings page appears.

Bug 2 — ESC key does not return to workspace settings:
goBackFromWorkspaceSettingPages uses rootState.routes.at(-2) to determine whether the previous route was the Inbox (REPORTS_SPLIT_NAVIGATOR). Before this PR the root stack could contain WORKSPACE_NAVIGATOR directly, so at(-2) pointed at a concrete navigator name. After this PR, every full-screen navigator is wrapped inside a single TAB_NAVIGATOR entry. With the new structure rootState.routes.at(-2) may now point at a TAB_NAVIGATOR route whose focused tab is WORKSPACE_NAVIGATOR, not REPORTS_SPLIT_NAVIGATOR. The updated code does call getActiveTabName to unwrap the tab, but goBackFromWorkspaceSettingPages checks whether the previous route is Inbox to decide whether to dismissModal or goBack(WORKSPACES_LIST). When the workspace was opened from the Workspaces tab (not Inbox), the fallback Navigation.goBack(ROUTES.WORKSPACES_LIST.route) fires — but because the Workspaces List is now a tab screen inside TAB_NAVIGATOR, goBack no longer navigates back to it correctly, resulting in the ESC key appearing to do nothing or navigating to the wrong destination.

Both bugs are staging-only (not reproducible in production), which is consistent with this being a new PR introduced in this staging release cycle.

The melvin-bot also explicitly assigned this issue to the PR author referencing PR #85234, confirming the automated system flagged the same PR.

Verification

• Affected files: src/pages/workspace/WorkspaceInitialPage.tsx, src/libs/Navigation/helpers/goBackFromWorkspaceSettingPages.ts, src/libs/Navigation/AppNavigator/Navigators/WorkspaceNavigator.tsx, src/libs/Navigation/AppNavigator/AuthScreens.tsx
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 directly modifies all of these files as confirmed by gh pr view 85234 --json files.
• Merge date: 2026-04-24 — aligns with the staging version 9.3.62-5 where the bug was first reported.
• The issue is staging-only (not reproducible in production), consistent with being introduced by a PR in the current staging cycle.

Root Cause

PR #85234 replaced the flat root stack structure (where WORKSPACE_NAVIGATOR was a direct child of RootStack) with a TabNavigator that contains all full-screen navigators as tab screens. This changed how navigation state is shaped at the root level. Two specific consequences:

1. The lazy initialisation of tab screens (tabs are not mounted until first visited) causes a perceptible delay when the app navigates into a freshly-created workspace's settings screen, because the WORKSPACE_NAVIGATOR tab screen has to be set up for the first time.

2. goBackFromWorkspaceSettingPages computes the "previous" route by reading rootState.routes.at(-2). Under the old architecture this was the prior full-screen navigator; under the new architecture there is only one TAB_NAVIGATOR entry at the root, so "go back to WORKSPACES_LIST" via Navigation.goBack(ROUTES.WORKSPACES_LIST.route) no longer functions as intended — the Workspaces List is now a nested screen inside the tab navigator, not a standalone route on the root stack that goBack can pop to.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #85234 moved WORKSPACE_NAVIGATOR from being a direct child of the root stack to being a tab inside TAB_NAVIGATOR. Two code paths were not updated for this structural change:

Bug 1 (Delay): When creating a workspace from the confirmation modal (RHP), App.ts:636-639 calls dismissModal with an afterTransition callback. Inside Navigation.ts:782-803, this chains two TransitionTracker.runAfterTransitions calls sequentially — each with up to a 1000ms safety timeout (CONST). Combined with lazy loading of the WorkspaceNavigator chunk (TabNavigator.tsx:22), this produces a noticeable delay.

Bug 2 (ESC): EscapeHandler.tsx:64 checks if the root stack's last route is WORKSPACE_NAVIGATOR. After the tab navigator change, the last root route is TAB_NAVIGATOR, so this condition is always false. The code falls through to dismissModal(), which also does nothing because TAB_NAVIGATOR is not in MODAL_ROUTES_TO_DISMISS. Result: ESC is completely broken on workspace settings.

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

Bug 2 (ESC — clear fix): Update EscapeHandler.tsx to account for the new navigation hierarchy. Instead of checking if the root stack's last route is WORKSPACE_NAVIGATOR, check if the focused tab inside TAB_NAVIGATOR is WORKSPACE_NAVIGATOR. Then update handleEscapeKeyInWorkspaceNavigator to navigate through the correct nesting level (root → TAB_NAVIGATOR → WORKSPACE_NAVIGATOR → split navigator) when popping.

Bug 1 (Delay): The double runAfterTransitions chain in dismissModal is the main contributor. The second wait (with waitForUpcomingTransition: true) can hit a 1-second safety timeout if the dismiss transition event doesn't fire as expected in the new tab structure. Consider either:

1. Skipping the dismissModal path when navigating to a tab screen (since tab switching doesn't need a modal dismiss animation), or
2. Navigating directly via Navigation.navigate with forceReplace: true when the destination is a tab within TAB_NAVIGATOR.

What alternative solutions did you explore?

For Bug 2, an alternative would be to add TAB_NAVIGATOR to the modal dismiss logic, but that's incorrect — tabs aren't modals. The proper fix is to traverse into TAB_NAVIGATOR's state to find the active workspace navigator.

For Bug 1, reducing the timeout constants would help symptomatically but wouldn't address the root cause of unnecessary transition waits for tab-to-tab navigation.

Investigation details

Navigation hierarchy after PR #85234:

Root Stack → TAB_NAVIGATOR → WORKSPACE_NAVIGATOR → WORKSPACE_SPLIT_NAVIGATOR → WorkspaceInitialPage

Bug 2 trace:

1. User presses ESC on workspace settings
2. EscapeHandler checks navigationRef.getRootState()?.routes.at(-1)?.name === NAVIGATORS.WORKSPACE_NAVIGATOR — false (it's TAB_NAVIGATOR)
3. Falls through to Navigation.dismissModal()
4. handleDismissModalAction checks if last route is in MODAL_ROUTES_TO_DISMISS — TAB_NAVIGATOR is not
5. Returns null, nothing happens

Bug 1 trace:

1. createWorkspaceWithPolicyDraftAndNavigateToIt → isTopmostRouteModalScreen() is true (workspace creation page is in RHP)
2. dismissModal({afterTransition: () => navigate(route)}) called
3. First runAfterTransitions wait (up to 1000ms) → dispatches DISMISS_MODAL
4. Second runAfterTransitions with waitForUpcomingTransition: true (up to 1000ms for transition start + 1000ms for completion)
5. afterTransition callback fires → Navigation.navigate to workspace route
6. React.lazy() loads WorkspaceNavigator chunk → renders

Key files: EscapeHandler.tsx, App.ts, Navigation.ts, TabNavigator.tsx

---

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.