[Due for payment 2026-07-13] [$250] Workspace - When new workspace is created on narrow screen, previous page is briefly visible

[lanitochka17]

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.75-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90044
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

1. Open the staging.new.expensify.com website.
2. Switch to narrow layout.
3. Navigate to "Workspaces"
4. Click on "New Workspace" > Submit the confirmation modal.
5. Note that before landing on new workspace´s overview page, previous page is briefly visible.

Expected Result:

After finishing the new workspace creation flow, user should automatically land on overview page of the new workspace, without any previous page as workspaces list being briefly visible before.

Actual Result:

After finishing workspace creation flow on a narrow layout, workspaces list page is briefly visible before user lands on the overview of the just created workspace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7157137_1779110797267.N3.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056397547191917025
• Upwork Job ID: 2056397547191917025
• Last Price Increase: 2026-05-18

Issue Owner

Current Issue Owner: @eVoloshchak

[MelvinBot]

Proposal

What is the root cause of that problem?

When a new workspace is created on narrow layout, the RHP (confirmation page) dismiss animation starts before React has finished rendering the new workspace page underneath. The dismiss relies on waitForTransition to delay popping the RHP until the destination page is ready. However, the tab switch to WORKSPACE_NAVIGATOR uses animation: NONE, which means no transitionStart/transitionEnd events fire. So TransitionTracker sees zero active transitions and fires the dismiss callback synchronously — defeating the wait entirely.

The sequence is:

1. pushNewlyCreatedWorkspaceUnderActiveModal pushes the workspace route into TAB_NAVIGATOR under the RHP.
2. revealRouteBeforeDismissingModal dispatches REPLACE_FULLSCREEN_UNDER_RHP (frame 1), then dismissModal with waitForTransition: true (frame 2).
3. Since the tab switch produces no tracked transition, the dismiss fires immediately — only ~2 animation frames after the workspace route was pushed, before React has committed the workspace page render.
4. The RHP slides away, briefly revealing the previous page (workspaces list or home) underneath.

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

In revealRouteBeforeDismissingModal, when on narrow layout, instead of relying solely on waitForTransition (which is a no-op for non-animated tab switches), manually start a TransitionTracker transition before dispatching REPLACE_FULLSCREEN_UNDER_RHP and end it after the destination screen has mounted/rendered. This could be done by:

1. Calling TransitionTracker.startTransition() before the REPLACE_FULLSCREEN_UNDER_RHP dispatch.
2. Using InteractionManager.runAfterInteractions or an additional requestAnimationFrame chain (3-4 frames instead of 2) to end the transition once the new screen has had time to render.

This ensures dismissModal's waitForTransition actually waits for the workspace page to appear before starting the dismiss animation.

What alternative solutions did you explore? (Optional)

An alternative is to use preInsertFullscreenUnderRHP earlier in the flow (e.g., when the confirmation form first mounts rather than on submit) to give React more time to render the workspace page. However, this would add complexity around cleanup if the user cancels, and the TransitionTracker approach is more targeted at the actual timing gap.

Related issues

• Workspace - Home page is displayed before landing on workspace overview page #88968 — Same symptom on native apps (iOS/Android hybrid): home page briefly visible during workspace creation. Likely the same root cause.
• [Due for payment 2026-07-08] [$250] Two workspaces screens in the navigation history after creating a workspace using FAB #90776 — Related navigation issue: two workspaces screens in history after FAB workspace creation. Possibly caused by the same pushNewlyCreatedWorkspaceUnderActiveModal + REPLACE_FULLSCREEN_UNDER_RHP double-dispatch.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @eVoloshchak (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022056397547191917025

[wildan-m]

Proposal

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

On narrow layout, when the user submits the "New Workspace" confirmation form (Workspaces list → New Workspace → Submit), the workspaces list is briefly visible during the transition animation before the new workspace's overview page settles into place. The user expects the new workspace screen to appear without the workspaces list flashing through.

What is the root cause of that problem?

The narrow-layout submit handler in WorkspaceConfirmationPage.tsx runs TWO navigation primitives back-to-back that each try to place the new workspace screen underneath the open RHP. The second one re-introduces WORKSPACES_LIST underneath the new workspace screen, which is exactly the route that briefly shows during the dismiss animation.

The submit handler computes the target route, calls pushNewlyCreatedWorkspaceUnderActiveModal synchronously, and then calls createWorkspaceWithPolicyDraftAndNavigateToIt:

App/src/pages/workspace/WorkspaceConfirmationPage.tsx

Lines 39 to 71 in 93d3bdd

	const onSubmit = (params: WorkspaceConfirmationSubmitFunctionParams) => {
	const policyID = params.policyID || generatePolicyID();
	const isDifferentOwner = !!params.owner && params.owner !== (currentUserPersonalDetails.email ?? '');
	const shouldShowSuccessPage = isDifferentOwner && !params.makeMeAdmin;
	const workspaceRoute = isSmallScreenWidth ? ROUTES.WORKSPACE_INITIAL.getRoute(policyID) : ROUTES.WORKSPACE_OVERVIEW.getRoute(policyID);
	const routeToNavigate = shouldShowSuccessPage ? ROUTES.WORKSPACE_CONFIRMATION_SUCCESS : workspaceRoute;
	if (!shouldShowSuccessPage) {
	// Mount the new workspace under this RHP so the dismiss animation reveals it instead of flashing WORKSPACES_LIST.
	const targetScreen = isSmallScreenWidth ? SCREENS.WORKSPACE.INITIAL : SCREENS.WORKSPACE.PROFILE;
	pushNewlyCreatedWorkspaceUnderActiveModal(targetScreen, policyID);
	}
	createWorkspaceWithPolicyDraftAndNavigateToIt({
	introSelected,
	policyOwnerEmail: params.owner,
	policyName: params.name,
	transitionFromOldDot: false,
	makeMeAdmin: params.makeMeAdmin,
	backTo: '',
	policyID,
	currency: params.currency,
	file: params.avatarFile as File,
	routeToNavigateAfterCreate: routeToNavigate,
	lastUsedPaymentMethod: lastPaymentMethod?.[policyID] as LastPaymentMethodType,
	activePolicy,
	currentUserAccountIDParam: currentUserPersonalDetails.accountID,
	currentUserEmailParam: currentUserPersonalDetails.email ?? '',
	shouldCreateControlPolicy: isSubscriptionTypeOfInvoicing(privateSubscription?.type),
	type: params.planType,
	isSelfTourViewed,
	betas,
	hasActiveAdminPolicies,
	isAnnualSubscription,
	});

The first primitive, pushNewlyCreatedWorkspaceUnderActiveModal, dispatches a CommonActions.navigate targeted at TAB_NAVIGATOR's state with initial: false, switching the active tab to WORKSPACE_NAVIGATOR and deliberately suppressing the WORKSPACES_LIST seed route so the dismiss animation reveals the new workspace directly:

App/src/libs/Navigation/helpers/pushNewlyCreatedWorkspaceUnderActiveModal.ts

Lines 18 to 40 in 93d3bdd

	function pushNewlyCreatedWorkspaceUnderActiveModal(targetScreen: WorkspaceTargetScreen, policyID: string) {
	const rootState = navigationRef.getRootState();
	const tabRoute = rootState?.routes.findLast((r) => r.name === NAVIGATORS.TAB_NAVIGATOR);
	const tabStateKey = tabRoute?.state?.key;
	if (!tabStateKey) {
	return;
	}
	navigationRef.dispatch({
	...CommonActions.navigate({
	name: NAVIGATORS.WORKSPACE_NAVIGATOR,
	params: {
	initial: false,
	screen: NAVIGATORS.WORKSPACE_SPLIT_NAVIGATOR,
	params: {
	screen: targetScreen,
	params: {policyID},
	},
	},
	}),
	target: tabStateKey,
	});
	}

After this dispatch the WORKSPACE_NAVIGATOR tab's nested state is [WORKSPACE_SPLIT_NAVIGATOR(WORKSPACE.INITIAL)] — single entry, no list underneath.

The second primitive, createWorkspaceWithPolicyDraftAndNavigateToIt, fires inside an isNavigationReady continuation. Because the RHP (WorkspaceConfirmationPage) is still the topmost route and the destination is a fullscreen route, the function falls through to Navigation.revealRouteBeforeDismissingModal(routeToNavigate):

App/src/libs/actions/App.ts

Lines 633 to 650 in 93d3bdd

	if (transitionFromOldDot) {
	Navigation.navigate(routeToNavigate);
	} else if (Navigation.isTopmostRouteModalScreen()) {
	// `revealRouteBeforeDismissingModal` only works for fullscreen targets. Modal targets
	// (e.g. workspace confirmation success) still need to open after the current RHP closes.
	if (willRouteNavigateToRHP(routeToNavigate)) {
	Navigation.dismissModal({
	afterTransition: () => Navigation.navigate(routeToNavigate),
	});
	return;
	}
	Navigation.revealRouteBeforeDismissingModal(routeToNavigate);
	} else {
	Navigation.navigate(routeToNavigate, {forceReplace: true});
	}
	});

revealRouteBeforeDismissingModal dispatches REPLACE_FULLSCREEN_UNDER_RHP for the same target tab, which enters handleReplaceFullscreenUnderRHP's tab-switch branch:

App/src/libs/Navigation/AppNavigator/createRootStackNavigator/GetStateForActionHandlers.ts

Lines 376 to 429 in 93d3bdd

	if (targetRoute.name === NAVIGATORS.TAB_NAVIGATOR) {
	const tabNavIndex = routesWithoutRHP.findLastIndex((r) => r.name === NAVIGATORS.TAB_NAVIGATOR);
	if (tabNavIndex < 0) {
	return null;
	}
	const existingTabRoute = routesWithoutRHP.at(tabNavIndex);
	const existingTabState = existingTabRoute?.state as NavigationState | undefined;
	if (!existingTabRoute || !existingTabState?.routes?.length) {
	return null;
	}
	const focusedTargetTab = getFocusedRouteFromNavigatorState(targetRoute.state);
	if (!focusedTargetTab) {
	return null;
	}
	const targetTabIndex = existingTabState.routes.findIndex((r) => r.name === focusedTargetTab.name);
	if (targetTabIndex < 0) {
	return null;
	}
	// Only update the target tab's nested state; all other tabs are left intact.
	const updatedTabRoutes = existingTabState.routes.map((r, i) => {
	if (i !== targetTabIndex) {
	return r;
	}
	// Prepend the existing sidebar/root route (e.g. Inbox) to the incoming state when
	// it starts with a different screen, so back navigation from the new screen
	// lands on the sidebar. When the existing tab doesn't have nested
	// routes (e.g. cold-start through a deep link that opens straight into a modal),
	// fall back to the split navigator's default sidebar route so there is still
	// something to pop back to.
	let mergedNestedState = focusedTargetTab.state;
	const existingNestedRoutes = (r.state as PartialState<NavigationState> | undefined)?.routes;
	const newNestedRoutes = focusedTargetTab.state?.routes;
	const existingFirstRoute = existingNestedRoutes?.at(0);
	const newFirstRoute = newNestedRoutes?.at(0);
	const defaultSidebarRouteName = r.name in SPLIT_TO_SIDEBAR ? SPLIT_TO_SIDEBAR[r.name as keyof typeof SPLIT_TO_SIDEBAR] : undefined;
	const sidebarRoute: NavigationPartialRoute | undefined = existingFirstRoute ?? (defaultSidebarRouteName ? {name: defaultSidebarRouteName} : undefined);
	if (sidebarRoute && newFirstRoute && sidebarRoute.name !== newFirstRoute.name) {
	const prependedRoutes = [sidebarRoute, ...(newNestedRoutes ?? [])];
	mergedNestedState = {...focusedTargetTab.state, routes: prependedRoutes, index: prependedRoutes.length - 1};
	}
	// Strip any RN deep-link hint chain from `r.params`; otherwise RN would run a
	// follow-up NAVIGATE from it and override the `state` we splice below.
	const sanitizedRoute = withSanitizedDeepLinkParams(r, focusedTargetTab.params as Record<string, unknown> | undefined);
	return {
	...sanitizedRoute,
	...(mergedNestedState !== undefined ? {state: mergedNestedState as typeof r.state} : {}),
	};
	});
	const updatedTabState = {...existingTabState, routes: updatedTabRoutes, index: targetTabIndex};
	const updatedTabRoute = {...existingTabRoute, state: updatedTabState} as StackNavigationState<ParamListBase>['routes'][number];
	// Save original route so handleRemoveFullscreenUnderRHP can fully restore it on cancel.
	preInsertedOriginalTabRoute = existingTabRoute;
	const newRoutes = [...routesWithoutRHP.slice(0, tabNavIndex), updatedTabRoute, ...routesWithoutRHP.slice(tabNavIndex + 1), rhpRoute];
	return stackRouter.getRehydratedState({...state, routes: newRoutes, index: newRoutes.length - 1}, configOptions);

That handler compares the existing tab's first nested route with the new state's first nested route to decide whether to prepend a "sidebar" route so back from the destination lands sensibly:

App/src/libs/Navigation/AppNavigator/createRootStackNavigator/GetStateForActionHandlers.ts

Lines 405 to 415 in 93d3bdd

	let mergedNestedState = focusedTargetTab.state;
	const existingNestedRoutes = (r.state as PartialState<NavigationState> | undefined)?.routes;
	const newNestedRoutes = focusedTargetTab.state?.routes;
	const existingFirstRoute = existingNestedRoutes?.at(0);
	const newFirstRoute = newNestedRoutes?.at(0);
	const defaultSidebarRouteName = r.name in SPLIT_TO_SIDEBAR ? SPLIT_TO_SIDEBAR[r.name as keyof typeof SPLIT_TO_SIDEBAR] : undefined;
	const sidebarRoute: NavigationPartialRoute | undefined = existingFirstRoute ?? (defaultSidebarRouteName ? {name: defaultSidebarRouteName} : undefined);
	if (sidebarRoute && newFirstRoute && sidebarRoute.name !== newFirstRoute.name) {
	const prependedRoutes = [sidebarRoute, ...(newNestedRoutes ?? [])];
	mergedNestedState = {...focusedTargetTab.state, routes: prependedRoutes, index: prependedRoutes.length - 1};
	}

Because the FIRST primitive already overwrote the tab's first nested route to be WORKSPACE_SPLIT_NAVIGATOR (the new workspace), and getStateFromPath(WORKSPACE_INITIAL) seeds its first nested route as WORKSPACES_LIST (the stack navigator's initial), the names differ, so the handler prepends WORKSPACES_LIST underneath the new workspace. The final WORKSPACE_NAVIGATOR nested routes become [WORKSPACE_SPLIT_NAVIGATOR(new), WORKSPACES_LIST, WORKSPACE_SPLIT_NAVIGATOR(new)] with index: 2.

When the RHP then dismisses, the focused screen is the final WORKSPACE_SPLIT_NAVIGATOR. But the intermediate WORKSPACES_LIST is now physically rendered just below it during the modal slide-out, so for a frame or two it shows through the transition — exactly the "previous page briefly visible" symptom reported.

The two primitives are doing the same job (pre-mount the new workspace under the open RHP so the dismiss reveals it). Running both in sequence on narrow layout is what re-introduces the list and produces the flash.

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

The pre-mount done by pushNewlyCreatedWorkspaceUnderActiveModal on narrow layout already fully sets up the destination state under the RHP. The subsequent revealRouteBeforeDismissingModal inside createWorkspaceWithPolicyDraftAndNavigateToIt is redundant and is what re-introduces WORKSPACES_LIST. The fix is to make the post-create step skip the second insert when a pre-mount has already happened, and just dismiss the modal.

The codebase already has a flag for exactly this kind of "two primitives, one outcome" coordination: isFullscreenPreInsertedUnderRHP in Navigation.ts. The expense-create flow uses it via Navigation.getIsFullscreenPreInsertedUnderRHP() to choose between "reveal + dismiss" and "just dismiss". We can hook into the same flag from the workspace pre-mount path:

1. In Navigation.ts, export a small setter (e.g. markFullscreenPreInsertedUnderRHP) that toggles the existing isFullscreenPreInsertedUnderRHP flag without going through preInsertFullscreenUnderRHP's dispatch — because the workspace path has already done its own dispatch via pushNewlyCreatedWorkspaceUnderActiveModal.

2. In pushNewlyCreatedWorkspaceUnderActiveModal, after the CommonActions.navigate dispatch succeeds, call markFullscreenPreInsertedUnderRHP() only on narrow layout (the helper's bug only manifests on narrow — wide layout never reaches the duplicating reveal because the target is an RHP route).

3. In createWorkspaceWithPolicyDraftAndNavigateToIt, inside the else if (Navigation.isTopmostRouteModalScreen()) branch, before falling through to revealRouteBeforeDismissingModal, check Navigation.getIsFullscreenPreInsertedUnderRHP(). If it is set, call Navigation.clearFullscreenPreInsertedFlag() then Navigation.dismissModal() and return — skipping the duplicating REPLACE_FULLSCREEN_UNDER_RHP.

With this change, the narrow-layout post-create WORKSPACE_NAVIGATOR nested state stays at [WORKSPACE_SPLIT_NAVIGATOR(new)] with index: 0. There is no intermediate WORKSPACES_LIST beneath the new workspace, so the modal dismiss animation reveals the new workspace directly with nothing flashing through.

The wide-layout path is unaffected because it never enters revealRouteBeforeDismissingModal for this flow (willRouteNavigateToRHP(WORKSPACE_OVERVIEW) returns false there only when the destination is a fullscreen, but the wide-layout reveal branch is dismissModal({afterTransition: navigate}) for RHP targets — and the workspace overview is a central-pane route that the existing flow handles correctly).

Other callers of createWorkspaceWithPolicyDraftAndNavigateToIt (e.g. the OldDot transition path) do not call pushNewlyCreatedWorkspaceUnderActiveModal and therefore never set the flag, so the new branch is skipped for them and behavior is unchanged.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/90985-fix-workspaces-list-flash-on-create?expand=1

What alternative solutions did you explore? (Optional)

An alternative is to push the equality check down into handleReplaceFullscreenUnderRHP itself: when the target tab's currently-focused leaf route already matches the new state's focused leaf route (same screen, same policyID param), treat the REPLACE_FULLSCREEN_UNDER_RHP as a no-op for state and only schedule the dismiss. This would make the action self-protect against duplicate pre-mounts and cover any future flow that double-mounts.

The trade-off is that it relies on params-equality across an action-state boundary that React Navigation's stack router does not normally expose, and it hides the coordination problem rather than fix it at the source. Reusing the existing isFullscreenPreInsertedUnderRHP flag — already designed for exactly this scenario in the expense-create flow — keeps the contract explicit and matches an in-codebase pattern.

[KJ21-ENG]

Proposal

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

On narrow layout, after creating a workspace from the Workspaces page, the app briefly shows the previous Workspaces list before landing on the newly-created workspace page.

What is the root cause of that problem?

The workspace creation confirmation flow now does two overlapping navigation operations while the RHP is still open.

First, WorkspaceConfirmationPage pre-mounts the new workspace under the active RHP so the modal can dismiss over the final destination instead of the previous Workspaces list (WorkspaceConfirmationPage.tsx#L45-L48, pushNewlyCreatedWorkspaceUnderActiveModal.ts#L26-L39).

Then createWorkspaceWithPolicyDraftAndNavigateToIt still enters the generic topmost-modal path and calls Navigation.revealRouteBeforeDismissingModal(routeToNavigate) for the same workspace route (App.ts#L636-L647). That generic reveal handler rebuilds the tab target and intentionally prepends the existing sidebar/root route when the incoming workspace route starts with a different screen (GetStateForActionHandlers.ts#L399-L415). In this flow the existing sidebar/root route is WORKSPACES_LIST, so the second reveal can put the list back into the visible transition path even though the workspace was already mounted underneath the RHP.

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

Make the workspace confirmation submit path use a single reveal strategy.

Concretely, when WorkspaceConfirmationPage successfully calls pushNewlyCreatedWorkspaceUnderActiveModal(...) for a non-success-page workspace creation, pass an option into createWorkspaceWithPolicyDraftAndNavigateToIt such as hasPreMountedRouteUnderActiveModal / skipRevealRouteBeforeDismissingModal.

Then, in createWorkspaceWithPolicyDraftAndNavigateToIt:

• keep the existing savePolicyDraftByNewWorkspace(...) behavior unchanged;
• if the topmost route is modal and the caller says the destination is already mounted under it, call Navigation.dismissModal() directly instead of Navigation.revealRouteBeforeDismissingModal(routeToNavigate);
• keep the current willRouteNavigateToRHP(routeToNavigate) branch for modal destinations like the success page;
• keep the generic revealRouteBeforeDismissingModal path for other modal-origin workspace creation flows that have not pre-mounted a destination.

This keeps the already-mounted workspace route as the page revealed by the RHP dismissal and avoids letting the generic tab-rebuild logic reintroduce WORKSPACES_LIST during the narrow-layout transition.

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

Add a focused navigation unit test for the workspace creation path where:

1. the root state is TAB_NAVIGATOR > WORKSPACE_NAVIGATOR > WORKSPACES_LIST with the workspace confirmation RHP on top;
2. submitting creates/pre-mounts WORKSPACE_SPLIT_NAVIGATOR for the new policy under the RHP;
3. the create action dismisses the modal;
4. the resulting focused route is the new workspace route, and no intermediate WORKSPACES_LIST reveal/navigation is dispatched after submit.

Also keep a manual regression check on narrow web: Workspaces > New Workspace > confirm, verify the list does not flash before the new workspace page appears.

[wildan-m]

Proposal updated — added compare branch with implementation.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

The WorkspaceConfirmationPage is rendered inside the Right-Hand Panel (RHP) modal (RightModalNavigator.tsx:327-330). On narrow layout, WorkspaceConfirmationPage.tsx:38 sets routeToNavigate = ROUTES.WORKSPACE_INITIAL.getRoute(policyID) and passes it to createWorkspaceWithPolicyDraftAndNavigateToIt.

Inside that function, when Navigation.isTopmostRouteModalScreen() is true, the code at App.ts:637-639 calls Navigation.dismissModal({ afterTransition: () => Navigation.navigate(routeToNavigate) }). The dismissModal dispatch starts the RHP closing animation immediately, which unmasks the screen underneath — the workspaces list page. The afterTransition callback only fires after the animation fully completes, so the workspaces list is visible for the entire duration of the slide-out before the workspace page is pushed.

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

I'd replace the dismissModal + afterTransition block at App.ts:637-639 with a single call to Navigation.revealRouteBeforeDismissingModal(routeToNavigate).

revealRouteBeforeDismissingModal (defined at Navigation.ts:990-1007) first inserts the destination route underneath the open RHP via a REPLACE_FULLSCREEN_UNDER_RHP dispatch, then in the next animation frame calls dismissModal. When the RHP slides away, it reveals the already-mounted workspace page — the workspaces list page is never exposed.

Scope: single change in src/libs/actions/App.ts, only the else if (Navigation.isTopmostRouteModalScreen()) branch. WorkspaceConfirmationPage.tsx and all navigation helpers remain untouched. The transitionFromOldDot branch and the fallback forceReplace branch at App.ts:634-641 are unaffected. Only the narrow-layout web path (Windows/Chrome) is impacted, since that is the only path where the RHP is the topmost modal at submission time.

What alternative solutions did you explore? (Optional)

Rejected: reduce the dismiss animation duration. This only shortens the flash rather than eliminating it, and would override shared animation config affecting other flows.

Rejected: call Navigation.navigate(routeToNavigate, { forceReplace: true }) directly without dismissing the modal. The else branch at App.ts:641 already does this for non-modal contexts, but skipping dismissModal when the RHP is open leaves the modal in the navigation stack and corrupts state.

Deferred: use preInsertFullscreenUnderRHP eagerly at WorkspaceConfirmationPage mount (Navigation.ts:1027). This "eager" approach pre-mounts the destination while the user is still filling in the form, giving React extra time. However, policyID is only finalized at submit time (generated via generatePolicyID() in WorkspaceConfirmationPage.tsx:37), so the route is not known at mount time. revealRouteBeforeDismissingModal at submit time is the simpler, correct fix.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @Abdulloh0109 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.