Web - Onboarding - Two Expensify logos appear on the modal

[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.43-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-12022/folder/13176924/41237589/1271692687
Email or phone of affected tester (no customers): dsnnsjdoisjnisdjoisww@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Other

Action Performed:

Precondition:

• App is in light mode.

1. Go to staging.new.expensify.com
2. Log in with new account.
3. On work email step, switch to dark mode on device.
   BUG 1: Expensify logo is hard to read on work email modal.
4. Click Step.
   BUG 2: Two Expensify logos appear on the modal.

Expected Result:

BUG 1: Expensify logo will switch theme after changing to dark mode.
BUG 2: Only one Expensify logo will be shown on the modal.

Actual Result:

BUG 1: Expensify logo is hard to read on work email modal.
BUG 2: Two Expensify logos appear on the modal.

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: @bernhardoj

[melvin-bot]

Triggered auto assignment to @Gonals (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85556 - "Preserve deep-linked report route during onboarding guard redirect" by @bernhardoj (Medium-High confidence)
Related Issues: None

Recommendation: REVERT

This PR modified the navigation stack handling for guard redirects. The change causes the onboarding modal to be layered on top of the SignInModal instead of replacing it, resulting in both modals being visible simultaneously and showing duplicate Expensify logos.

Labels: Keeping DeployBlockerCash (this is a frontend/App bug blocking the mobile deploy)

Detailed Analysis

Evidence

PR #85556 was merged on March 23, 2026 and is included in the staging deploy checklist for v9.3.43-0. The issue is reproducible on staging but not in production, confirming it was introduced in this release.

The PR modified src/libs/Navigation/AppNavigator/createRootStackNavigator/RootStackRouter.ts to preserve existing fullscreen routes when a navigation guard triggers a REDIRECT to onboarding. Before this PR, redirecting to onboarding would reset the navigation state to [Home, OnboardingModalNavigator]. After this PR (lines 105-111), if there is an existing route in the stack, it appends the onboarding modal on top: [...state.routes, redirectRoute].

Verification

The affected flow:

1. User signs in as a new account on staging
2. SignInModal is shown with ExpensifyWordmark (from SignInPageContent component)
3. After authentication completes, the OnboardingGuard fires a REDIRECT
4. PR Preserve deep-linked report route during onboarding guard redirect #85556 preserves the SignInModal in the stack and appends OnboardingModalNavigator on top
5. Result: Both SignInModal and OnboardingWorkEmail are in the navigation stack
6. When user reaches the work email step and switches to dark mode, both modals try to render their content, causing two Expensify logos to appear

The timing issue is exacerbated by the SignInModal code (lines 34-53) which waits for openApp() to complete before dismissing. With PR #85556, the OnboardingGuard can fire and modify the stack before Navigation.dismissModal() is called, resulting in both modals being present.

Root Cause

The navigation stack preservation logic in PR #85556 does not account for the case where the "existing route" is actually the SignInModal itself, which should be dismissed before showing onboarding. The code at line 105 checks state.routes.some((route) => isFullScreenName(route.name)) - if SignInModal is considered a fullscreen route, it gets preserved when it should be replaced.

The dark mode theme switch likely triggers a re-render that makes both logos visible at once, explaining why the bug manifests specifically when switching themes during onboarding.

[MelvinBot]

Proposal

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

When a new user signs in on staging and goes through onboarding, two Expensify logos appear on the modal. Additionally, when switching from light to dark mode during the work email step, the Expensify logo is hard to read because it bleeds through the overlay with hardcoded colors that don't adapt to the theme.

What is the root cause of that problem?

PR #85556 ("Preserve deep-linked report route during onboarding guard redirect"), merged March 23, changed the REDIRECT handler in RootStackRouter.ts to preserve existing routes when a fullscreen route is already in the stack.

The problem is at RootStackRouter.ts:105-111:

const hasExistingFullScreenRoute = state.routes.some((route) => isFullScreenName(route.name));
const routes = hasExistingFullScreenRoute && redirectRoute
  ? [...state.routes, redirectRoute]  // <-- preserves ALL routes, including modals
  : redirectState.routes;

During new-user sign-in flow, the navigation stack is: [Home/ReportsSplitNavigator, RightModalNavigator(SignInModal)]. When the OnboardingGuard fires a REDIRECT to onboarding:

1. hasExistingFullScreenRoute is true (Home is a fullscreen route per isNavigatorName.ts:6)
2. The spread [...state.routes, redirectRoute] preserves all existing routes, including RightModalNavigator containing SignInModal
3. Final stack becomes: [Home, RightModalNavigator(SignInModal), OnboardingModalNavigator]
4. SignInModal renders SignInPageContent which includes ExpensifyWordmark (SignInPageContent.tsx:33)
5. The onboarding overlay is only 72% opaque (variables.ts:126), so the SignInModal's ExpensifyWordmark logo bleeds through

BUG 1 (dark mode): The ExpensifyWordmark SVGs use hardcoded colors (e.g., #03d47c green, #e7ece9 light gray) that don't adapt to the theme. When visible through the overlay in dark mode, the light-colored portions of the logo clash with the dark background.

BUG 2 (two logos): The onboarding content is displayed on top of the overlay, while the preserved SignInModal's ExpensifyWordmark is visible behind it through the semi-transparent overlay — resulting in two logos.

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

In the REDIRECT handler in RootStackRouter.ts, when preserving existing routes, filter out non-fullscreen routes (modals) so they don't persist behind the redirect target:

At RootStackRouter.ts:111, change the route preservation logic to only keep fullscreen routes:

// Before (preserves everything including modals):
const routes = hasExistingFullScreenRoute && redirectRoute ? [...state.routes, redirectRoute] : redirectState.routes;

// After (only preserves fullscreen routes):
const filteredRoutes = state.routes.filter((route) => isFullScreenName(route.name));
const routes = hasExistingFullScreenRoute && redirectRoute ? [...filteredRoutes, redirectRoute] : redirectState.routes;

This preserves the original intent of PR #85556 (keeping deep-linked report routes for post-onboarding return) while properly discarding modal navigators that should not persist behind the redirect overlay.

What alternative solutions did you explore? (Optional)

An alternative would be to have SignInModal dismiss itself before the OnboardingGuard fires by adjusting the timing in SignInModal.tsx:44-51. However, this is fragile because it depends on execution order of promises and guard evaluation, which is a race condition. Fixing the route preservation logic is more robust since it correctly scopes which routes should be preserved regardless of timing.

---

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.

[Gonals]

This seems like a very corner flow, so we may not need to block on it. Thoughts, @grgia?

[bernhardoj]

@Gonals Tested on main and staging, but I can't repro it. There is no Expensify logo on the onboarding modal at all.

w.mp4

w2.mp4