Navigation - Tap on view from email opens the Home if any other tab is open before

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.74-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
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/72925117/folder/54013402/41237079/1738376027
Email or phone of affected tester (no customers): emady.syed1234+bhangra@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Realme C21Y / Android 11
App Component: Chat Report View

Action Performed:

Precondition
WS admin setup different workflows so that the expense on emails appears with different buttons (Disable Approvals, Delay Submissions is On and set to Manual, Enable payments)
As submitter > submit an expense report which contain one scan and one distance expense
As submitter > submit an expense

1. As WS OWNER open App and go to inbox
2. Background expensify app and open mailbox
3. Open email from precondition
4. Go to spend tab and repeat step 2 and 3

Expected Result:

App should open WS chat and scroll to the report.

Actual Result:

App opens to Home.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7254662_1788914914073.XRecorder_20260909_08.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7254662

Issue Owner

Current Issue Owner: @yusufdeveloper2903

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/5d05c2470048657c25b2b6fd4a22ff7e525be03ca4fce33cdfd5c6790ee253d6

[MelvinBot]

Proposal

⚠️ Medium confidence. The code path is fully traced, but I could not run the app on Android to confirm which of two candidate reduction steps actually fires. Discriminating log lines are listed at the bottom.

What is the root cause of that problem?

For a signed-in user, an OS deep link is handled entirely by react-navigation. Expensify's own handler deliberately bails out:

src/libs/actions/Link.ts:617-620 — openReportFromDeepLink() returns early with the comment "Navigation for signed users is handled by react-navigation." So there is no App-level safety net if react-navigation drops the link.

React-navigation's warm-link path then does this:

1. linkingConfig/subscribe.ts:39-71 forwards the URL (authenticated /r/<id> links are not filtered out).
2. getAdaptedStateFromPath.ts:327-331 expands the parsed route into the full 5-tab strip with index 1 (Inbox) focused. This part is correct and reads no current state — it is identical whichever tab you were on.
3. getActionFromState then throws that tab strip away and collapses it into a single NAVIGATE TabNavigator { initial: false, screen: 'ReportsSplitNavigator', ... }. The initial: false flag is produced precisely because SCREENS.HOME is both TAB_SCREENS[0] (TAB_SCREENS.ts:9) and the tab navigator's initialRouteName (config.ts:2193-2194).
4. initial: false tells react-navigation not to seed the tab navigator's state from those params. The tab navigator instead initializes from Expensify's router override at TabNavigator.native.tsx:84-86 — preserved tab state if any, otherwise initialRouteName: SCREENS.HOME. The compensating nested NAVIGATE ReportsSplitNavigator that is supposed to run afterwards is conditional and can be silently skipped.

Why it is tab-dependent: when Inbox was the last-focused tab, the tab navigator's own initial/preserved state already is the reports tab, so the report renders and the dropped nested navigate is invisible. When Spend (or any other tab) was focused, nothing re-selects the reports tab and you land on the initial route — Home.

This exact failure mode has bitten us before: Expensify/App#95942 reverted a fix whose commit message reads "A deep link or notification that dispatches a nested NAVIGATE during that window is unhandled and silently dropped." That gate is not in the tree today.

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

Stop letting the correct, fully-formed adapted state get collapsed into a lossy nested NAVIGATE. Two options, in order of preference:

1. Apply the deep-link state directly. In linkingConfig/subscribe.ts, intercept the URL for authenticated users and route it through the App's own linkTo helper, which reconciles against the live navigation state and already carries all the tab-aware fixups. The generic linking listener currently uses none of them.
2. Or make the deep link authoritative over preserved tab state. Have the tab navigator's getInitialState override at TabNavigator.native.tsx:84-86 prefer an incoming deep-link target over getPreservedNavigatorState(route.key), so a pending link always wins over "whatever tab you had open".

Either way, add a regression test that dispatches a /r/<id> link onto a live navigation state whose focused tab is Spend, and asserts the resulting focused route is SCREENS.REPORT. Existing coverage only exercises the Inbox case, which is exactly why this slipped through.

What alternative solutions did you explore? (Optional)

Ruled out, with evidence

• A "tab mismatch → Home" fallback. There isn't one. The only explicit Home fallbacks are getDefaultFullScreenRoute (getAdaptedStateFromPath.ts:283-297) and the RHP_TO_HOME map, and neither is reachable for /r/<id> because a fullscreen route already resolves.
• TabSwitchGuardContext swallowing the navigation. It only reacts to tabPress events on in-screen OnyxTabNavigator tabs. A deep link never emits tabPress.
• deferNavigate. A one-microtask defer used only in the scan flow; not on this path and it cannot drop a navigation.
• Cold start restoring lastVisitedPath. Plausible on a 2GB Realme C21Y where Android kills the backgrounded process (NavigationRoot.tsx:174-184), but it predicts landing back on Spend, not Home — which contradicts the reported result. Kept as a secondary hypothesis only.
• The root-path alias. Expensify/App#97446 (2026-07-30) made / resolve to Home instead of Inbox. If the email button hands NewDot a bare URL, that alone lands on Home — but it would fail from every tab, not just non-Inbox ones.

Verification gap: the Android intent handling for HybridApp lives in Mobile-Expensify, which I can't read. If the email "View" button routes through OldDot rather than a direct /r/<id> link, an internal engineer should confirm what URL actually reaches NewDot on onNewIntent.

Log lines that would settle this in one repro (adb logcat on the failing tap):

• Navigating to route — does /r/<id> ever appear before /home, or only /home?
• Restoring last visited path on app startup — if present, it was a cold start, not a warm dispatch.
• [Deep link] ... — distinguishes the cold getInitialURL path from the warm url event.
• On a debug build, react-navigation's The 'state' or 'screen' passed in the params couldn't be applied to the navigator would directly confirm the dropped-nested-params hypothesis.

Note on testing: this is an Android-native, background-resume deep link. I attempted a web-side check of the same tab-dependent behavior, but the web harness exposes no way to read or drive the address bar in-session, so it produced no usable signal either way.

Possibly related open issues

• Expensify/App#97159 — report opened via a /search/r/ deep link shows a skeleton with Home visible behind it. Same "deep link doesn't fully take over the tab" smell.
• Expensify/App#99940 — new user not navigated to Concierge after deeplinking. Different trigger, same subsystem.

Neither looks like a duplicate.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100680) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · no recording available

[j3ffffff]

Proposal

What is the root cause of that problem?

When a user taps an email "View" link while any non-Home tab is active (e.g. the Spend/Search tab), the navigation falls back to the Home screen instead of opening the workspace chat report.

The deep-link path for authenticated users is handled entirely by React Navigation's linking system (subscribe.ts → React Navigation's internal URL handler → getAdaptedStateFromPath). openReportFromDeepLink immediately returns for authenticated users (if (isAuthenticated) { return; }), so React Navigation is solely responsible for the navigation.

getAdaptedStateFromPath (src/libs/Navigation/helpers/getAdaptedStateFromPath.ts) builds the target navigation state by calling getDefaultFullScreenRoute. For a /r/:reportID URL, this function calls getReportOrDraftReport(reportID, undefined, undefined, {}) — passing an empty {} as the reportDraft argument (which forces shouldSkipDraft = true and disables the draft fallback) while still reading from the module-level deprecatedAllReports cache. When the report is found in Onyx, the function builds a correct target state: TAB_NAVIGATOR → REPORTS_SPLIT_NAVIGATOR (index 1) → [INBOX, REPORT]. When the report is not yet in Onyx, it falls back to REPORTS_SPLIT_NAVIGATOR without a specific report.

In both cases, the resulting root stack state is:

[ TAB_NAVIGATOR (REPORTS_SPLIT_NAVIGATOR selected), SCREENS.REPORT ]

React Navigation then calls getActionFromState on this target state to generate a NAVIGATE action. When the current active tab is SEARCH_FULLSCREEN_NAVIGATOR (Spend tab), the NAVIGATE action targets SCREENS.REPORT — which lives inside REPORTS_SPLIT_NAVIGATOR, a tab that is not currently mounted/active. The root stack navigator's action handler in GetStateForActionHandlers.ts does not correctly switch the TAB_NAVIGATOR to REPORTS_SPLIT_NAVIGATOR before navigating to the report, causing the navigation to fail. When the action cannot be handled, React Navigation falls back to inserting SCREENS.HOME as the default visible route (the first tab, index 0 in TAB_SCREENS).

When the user is already on the Home tab, REPORTS_SPLIT_NAVIGATOR is the immediately adjacent tab and SCREENS.REPORT is already accessible in the current navigation context, so NAVIGATE succeeds.

The buildTabNavigatorNestedState function (src/libs/Navigation/helpers/buildTabNavigatorNestedState.ts) also has a relevant safety net: if the selected tab name is not found in TAB_NAVIGATOR_ROUTES, it falls back to index = 0 (i.e. SCREENS.HOME). This can trigger if the tab state is reconstructed incorrectly during the tab switch.

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

In GetStateForActionHandlers.ts (the custom root stack navigator action handler), add handling for the case where a NAVIGATE action targets a screen (like SCREENS.REPORT) that lives inside a tab (REPORTS_SPLIT_NAVIGATOR) that is not currently the active tab:

1. When a NAVIGATE action arrives for a route that belongs inside REPORTS_SPLIT_NAVIGATOR and the current active tab is something else (e.g. SEARCH_FULLSCREEN_NAVIGATOR), first dispatch a NAVIGATE to the TAB_NAVIGATOR to switch to REPORTS_SPLIT_NAVIGATOR, then navigate to the specific report within it — similar to how swapBackgroundTabForRHPTarget.ts handles cross-tab navigation for RHP overlays.

2. Alternatively, ensure getAdaptedStateFromPath returns a state where the full tab context (including tab index and nested REPORTS_SPLIT_NAVIGATOR state with the report) is set correctly so that React Navigation's resetRoot call (which it falls back to when getActionFromState returns undefined) always lands on the correct report rather than SCREENS.HOME.

What alternative solutions did you explore? (Optional)

• Considered whether the issue was in getReportOrDraftReport passing {} as allReports (which would always return a fallback), but even without the report in Onyx the state still includes SCREENS.REPORT at the root level and should be navigable.
• Considered whether openReportFromDeepLink needed to handle warm-start authenticated cases the way it handles unauthenticated users — but this would duplicate React Navigation's linking work.

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[Eskalifer1]

@MelvinBot I see we have TC for that, so probably we already fixed it in the past, try to find that issue and what apprach was used

[MelvinBot]

Eskalifer1 — you're right, and the reason it's back is worse than a plain regression: we fixed it twice and reverted it twice, then closed and paid out the issue anyway. Nothing replaced the fix, so the defect has been live and untracked since 2026-07-13.

The prior issue

Expensify/App#91777 — "TabNavigator NAVIGATE action not handled during deep link login flow" (opened 2026-05-27, closed 2026-07-28 as Awaiting Payment).

Root cause on record there: TAB_NAVIGATOR is declared on the root navigator as soon as the authenticated RootStack renders, but it's lazily loaded via getComponent. waitForProtectedRoutes() resolves before the child router has actually mounted. A nested NAVIGATE dispatched in that window logs this and the link is silently dropped — leaving you on the default screen:

The action 'NAVIGATE' with payload {"name":"TabNavigator","params":{"initial":false,
"screen":"ReportsSplitNavigator","params":{...,"screen":"Report",
"params":{"reportID":"..."},"path":"/r/..."}}} was not handled by any navigator.

The two approaches, and why both were reverted

	Approach	Merged	Reverted
V1 #91796	Gated the shared waitForProtectedRoutes() primitive — required TAB_NAVIGATOR's nested state to be non-stale before resolving	2026-05-27	#92046, 2026-05-29
V2 #92482	New tabNavigatorReadiness.ts — a ref-counted mount signal. subscribe.ts deferred the URL instead of dropping it; openReportFromDeepLink chained .then(() => whenTabNavigatorReady())	2026-07-09	#95942, 2026-07-13

V1 failed because it gated a shared primitive. On a quiet cold start the promise never resolved and navigation hung outright — four deploy blockers: #92023, #92030, #92041, #92039.

V2 is the one that matters here. It was reverted for deploy blocker Expensify/App#95878, whose repro is "Background the app (do not kill) → open Gmail → open the email → tap Get started" — the same background-app-then-tap-email family as this issue. Two things about that revert:

• No root cause was ever written down. The entire thread is rlinoz saying "hmm maybe it is related to Gate deep-link navigation on TabNavigator mount via lifecycle signal #92482, let me check" at 11:42Z → revert merged at 14:04Z. It was a suspicion-driven blocker revert.
• It was then confirmed only by post-revert re-test, and m-natarajan logged "unable to reproduce" before the issue was closed.

Why the TC didn't protect us

The BrowserStack TC on this issue is 41237079; #95878's TC is 41237087 — adjacent IDs in the same project (2219752). So the test case you're remembering does trace to this family. But the unit regression test that guarded the fix, tests/unit/tabNavigatorReadinessTest.ts, was deleted along with the revert. I confirmed at d58c78e that nothing remains: zero hits across src/ and tests/ for tabNavigatorReadiness, whenTabNavigatorReady, isTabNavigatorMounted, or setTabNavigatorMounted. src/libs/actions/Link.ts:577 is back to a bare Navigation.waitForProtectedRoutes().then(...), and the only deep-link guard left in subscribe.ts:65 is the signed-out /r/ drop.

One honest caveat

The #91777 readiness race is tab-agnostic — on its own it doesn't explain why this only fails when a non-Inbox tab was active. So I'd treat V2 as the fix for the same observable symptom (deep link silently dropped → you land on the default screen), while the tab-dependence still points at preserved tab state winning over the deep link, per my earlier analysis. One runtime data point separates them: does the NAVIGATE ... was not handled by any navigator error appear in the Android console on the failing tap? If yes, this is a straight regression of #91777. If no, it's the tab-state path and needs a different fix.

What a V3 has to avoid, and the five issues I ruled out

Constraints on re-landing a readiness gate:

• Don't gate a shared primitive (V1's failure). Scope it to the deep-link path only.
• Don't sit a signed-out flow behind a promise that can only resolve after auth. My read of V2's likely failure — speculation, not stated anywhere — is that for a signed-out user TAB_NAVIGATOR never mounts, so whenTabNavigatorReady() never resolves and everything downstream of it in openReportFromDeepLink (including the anonymous-user → signOutAndRedirectToSignIn branch) never runs. That matches Emails-Invited to the WS member is not signed in after tapping Get started in the email #95878 exactly.
• Add a timeout/bailout so a missed mount signal degrades to "navigate anyway" rather than "hang".
• Before re-landing, get the real Emails-Invited to the WS member is not signed in after tapping Get started in the email #95878 diagnosis. The only place it might exist is the Slack threads in #expensify-open-source around 2026-07-13.

Ruled out — every one is a cold-start or sign-in-time path, not a warm authenticated deep link:

Issue	Fix	Why it doesn't apply
#94549 (Email → Home instead of WS chat)	#95418 added && !exitTo to isUserClickedSignIn	ValidateLoginPage/index.web.tsx — web only, signed-out, needs an exitTo param
#85242 (Home instead of room after sign-in)	#92834, after two prior reverts	Every branch gated on an onboarding-guard REDIRECT; no guard fires for an established WS owner
#94209 (app reopens last screen after kill)	No fix — closed as not a priority	Inverse request. Useful as intent evidence: its own text says a backgrounded app following a deep link should land deep
#97467 (root / lands on Inbox)	#97446 gave SCREENS.HOME the root alias	Doesn't apply — but may be why the drop now surfaces as Home rather than Inbox. Speculation; needs a bisect against 9.4.74-0
#88443 (Go-back-to-home opens Inbox)	#88563	Not-found-page button only, not a deep link

No test anywhere covers "deep link while a non-Inbox tab is focused." The two closest both miss: tests/unit/Navigation/guards/handleNavigationGuardRedirect.test.ts:131 asserts the inverse (a HOME redirect must reset tab index to 0), and tests/navigation/getAdaptedStateFromPathTabStripTests.ts only round-trips the parsed strip without ever dispatching through a live TabNavigator.

Also worth noting: #91777 was closed and paid out on 2026-07-28 — fifteen days after its fix was reverted. Nobody has been tracking the live defect since.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100680) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · view recording

[Eskalifer1]

I was not able to repro, let's see if someone could repro it and fix it

🆘 C+ Help Wanted