Android - Room - Back button in room reopens room when opening public room as guest

[applause-bot]

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.89-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91796
Email or phone of affected tester (no customers): sdjsodnjiodsjsoinj1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Chat Report View

Action Performed:

Precondition:

• Fresh install the app.
• Do not open Expensify app.

1. Open public room link in external app (eg, https://staging.new.expensify.com/r/6731266495832101)
2. Tap app back button on room chat.

Expected Result:

App will return to LHN.

Actual Result:

Back button in room reopens room when opening public room as guest.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165787_1780003500185.Screen_Recording_20260529_052159_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7165787

[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/80beaf9c33b3a6d34ed61a034708d763c00afb8da57eaa67d903be1eb90d7c6f

[melvin-bot]

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The early-return added by PR Expensify/App#91796 in src/libs/Navigation/linkingConfig/subscribe.ts:35-46 unconditionally suppresses React Navigation's URL listener whenever isTabNavigatorReady(state) is false. For a signed-out guest opening a public room via deeplink, the root navigator only renders PublicScreens, which never declares NAVIGATORS.TAB_NAVIGATOR (that screen is only declared inside AuthScreens.tsx:184-190). isTabNavigatorReady is therefore permanently false for guests, and the linking listener is permanently disabled.

When Android replays the original VIEW intent URL on system-back (a known Android behavior for activities launched from a deeplink), the URL hits Linking.addEventListener('url', …), gets short-circuited by the new guard, and React Navigation never pops the public-room route. The deeplink path in DeepLinkHandler.tsx:97-106 still calls openReportFromDeepLink (which re-pushes the room), so the result is that back-press visibly "reopens" the same room. The same gate was added to navContainsProtectedRoutes in Navigation.ts:697-712, so waitForProtectedRoutes() also never resolves for guests, which compounds the bad state.

The PR was scoped to fix an authenticated deep-link race (issue Expensify/App#91777) but the guest path was not considered: a guest has no TabNavigator at all, so there is no race to wait for — the listener should fire normally.

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

Tighten the gate so it only blocks the listener when a TabNavigator route actually exists but hasn't finished mounting. If there is no TabNavigator route at all (the guest / PublicScreens case), there is no unhandled-action risk, so the listener should run.

Apply this in both places PR #91796 added the readiness check:

1. src/libs/Navigation/linkingConfig/subscribe.ts:35-46 — only return early when a TabNavigator route is present AND not yet ready.
2. src/libs/Navigation/Navigation.ts:697-712 (navContainsProtectedRoutes) — same treatment, so waitForProtectedRoutes() can resolve for guests where no TabNavigator will ever mount.

Concretely: introduce a hasTabNavigatorRoute(state) helper next to isTabNavigatorReady and change the guard to "skip only if hasTabNavigatorRoute && !isTabNavigatorReady". This preserves the original PR #91796 fix for the auth deeplink race while restoring guest back-button behavior on public rooms.

What alternative solutions did you explore?

• Revert PR Wait for TabNavigator mount before resolving waitForProtectedRoutes #91796 — would fix the deploy blocker but reintroduce the NAVIGATE console error fixed in issue [$250] TabNavigator NAVIGATE action not handled during deep link login flow #91777.
• Gate on auth/session state (e.g., isAnonymousUser() or session credentials) instead of navigator presence — workable but couples Navigation helpers to session state. The navigator-presence check is the more direct signal for "is there a TabNavigator that could swallow this NAVIGATE?".
• Move the Linking subscribe gate into openReportFromDeepLink — larger refactor; the navigator-presence narrowing is the smaller, lower-risk change for a deploy blocker.

Investigation details / evidence chain

• PR diff: subscribe.ts added isTabNavigatorReady early-return; Navigation.ts:navContainsProtectedRoutes gated on same predicate; new helper isTabNavigatorReady.
• Guests render PublicScreens only: AppNavigator.native.tsx:15-33 mounts AuthScreens only when authenticated. PublicScreens declares Home / Validate / SAML / TestTools, no TAB_NAVIGATOR: PublicScreens.tsx:21-84.
• Two separate Linking subscribers exist — DeepLinkHandler.tsx:97-106 (calls openReportFromDeepLink and re-pushes the room) and the React Navigation linking listener in subscribe.ts (only one that pops the back-stack). Only the latter is gated, which is why pressing back visibly "reopens" the room instead of dropping back to LHN.
• openReportFromDeepLink calls waitForProtectedRoutes() in every branch (Link.ts:296-383) — since navContainsProtectedRoutes is also now gated on TabNavigator readiness, the guest waiter never resolves either.
• Alternative considered and refuted: a navigation-state mutation in restored TabNavigator state could in principle cause the loop, but PR Wait for TabNavigator mount before resolving waitForProtectedRoutes #91796's diff is purely the readiness check — no stack/state mutation was introduced — and the bug only appears after that merge.

---

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