[Due for payment 2026-05-07] QAB - App doesn't navigate to the Reports/Spend tab after create expense from QAB

[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: v9.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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-22585/folder/13176896/41237394/1371128471?sort=%2Bidentifier
#85234
Email or phone of affected tester (no customers): leungbratt6+2704@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Money Requests

Action Performed:

Preconditions: User has a Workspace and has created a manual expense before

1. Open the NewDot app, from not on the Inbox tab Workspace chat (any tab Home, Account...)
2. Click on the FAB - QAB - enter amount
3. Create the expense
4. Select another tabs (Home, Account...) and repeat the steps 2,3

Expected Result:

Navigate to the Reports/Spend tab

Actual Result:

Still stay on the current tab

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

[melvin-bot]

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

Recommendation: REVERT

PR #85234 introduced a major navigation refactor that changed the root navigation structure, and the new isReportTopmostSplitNavigator() logic does not correctly handle the tab-based navigation state when determining where to navigate after creating an expense from the QAB.

Assigned: @WojtekBoman (PR author), @ZhenjaHorbach, @mountiny (approving reviewers) from highest-confidence causing PR only
Labels: DeployBlockerCash kept (Frontend bug, App PR caused the issue). DeployBlocker not present, no change needed.

📋 Detailed Analysis

Evidence

• The issue body directly links PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 as the suspected cause.
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 is listed in the StagingDeployCash checklist (merged 2026-04-24, entry Updated styles for the sign in page #124 in the chronological list).
• The bug is staging-only (not reproduced in production), consistent with it being introduced by this new staging PR.
• The bug affects navigation after expense creation from the QAB when the user starts on the Home or Account tab.

Verification

• Affected files: src/libs/Navigation/helpers/isReportTopmostSplitNavigator.ts, src/libs/Navigation/helpers/navigateAfterExpenseCreate.ts, and the entire navigation stack transformation in src/libs/Navigation/AppNavigator/.
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 modifies these files: Confirmed — isReportTopmostSplitNavigator.ts and getActiveTabName.ts are in the PR's file list.

Root Cause

Before PR #85234, the navigation root stack contained REPORTS_SPLIT_NAVIGATOR, HOME, SETTINGS_SPLIT_NAVIGATOR, etc. as direct children of the root stack. isReportTopmostSplitNavigator() checked rootState.routes.findLast((route) => isFullScreenName(route.name))?.name === NAVIGATORS.REPORTS_SPLIT_NAVIGATOR.

After PR #85234, all tabs are wrapped in a single TAB_NAVIGATOR. The FULL_SCREENS_SET (in isNavigatorName.ts) now includes NAVIGATORS.TAB_NAVIGATOR. So rootState.routes.findLast((route) => isFullScreenName(route.name)) returns the TAB_NAVIGATOR route (not REPORTS_SPLIT_NAVIGATOR).

The updated isReportTopmostSplitNavigator() delegates to getActiveTabName(topmostFullScreenRoute) to inspect which tab is active inside the TAB_NAVIGATOR. When the user is on the Home or Account tab, getActiveTabName() correctly returns a non-reports tab name, so isReportTopmostSplitNavigator() returns false.

In navigateAfterExpenseCreate(), when isFromGlobalCreate=true, isUserOnInbox=false, and transactionID exists, the code calls navigateToSearch(). On wide layout (Windows/Chrome), this calls Navigation.revealRouteBeforeDismissingModal(ROUTES.SEARCH_ROOT.getRoute({query: queryString})) which dispatches a REPLACE_FULLSCREEN_UNDER_RHP action.

The handleReplaceFullscreenUnderRHP handler in GetStateForActionHandlers.ts resolves the Search route into a TAB_NAVIGATOR route (since Search is now a tab). It then tries to find an existing TAB_NAVIGATOR in routesWithoutRHP and switch to the Search tab within it. If this operation fails (e.g., the focusedTargetTab returned by getFocusedRouteFromNavigatorState does not match any tab in the existing state, or targetTabIndex is -1), the handler returns null — which means no navigation occurs and the user stays on the current tab.

The net result is the user stays on whatever tab they were on (Home, Account) instead of being taken to the Reports/Spend (Search/Expense) tab after creating the expense.