Back button - Does not navigate to LHN Home from "Hmm... it's not here" page`

[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.72-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/folder/13176685/test-cases/41236604
Email or phone of affected tester (no customers): testing210790@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: IPhone 11 IOS/27 beta
App Component: Other

Action Performed:

1.Navigate to the URLs https://staging.new.expensify.com/r/6821704960193694/details.
2.Verify the “Hmm... it’s not here” page is displayed.
3.Tap the Back button.
4.Wait for 1 second.
5.Tap the Back button again.
6.Verify that the user is redirected to the LHN Home page.

Expected Result:

After tapping Back twice, with a 1-second wait between taps, the user should be redirected to the LHN Home page.

Actual Result:

After tapping Back twice, the “Hmm... it’s not here” page remains displayed and the user is not redirected to the LHN Home page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7251153_1788527152008.WhatsApp_Video_2026-09-04_at_09.00.52.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7251153

Issue Owner

Current Issue Owner: @Pujan92

[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/f80c5f692fda9ce8199e832cf5686b309ea2f0e40615687fa3b8c681ac194f9f

[MelvinBot]

Proposal

What is the root cause of that problem?

Two separate not-found pages look identical, and the second one has no way out.

Deep-linking to /r/<reportID>/details builds a root stack of [TAB_NAVIGATOR, RIGHT_MODAL_NAVIGATOR], where the RHP holds the details page and the central pane underneath holds the Report screen for the same invalid reportID. Both render "Hmm... it's not here".

1. Back tap 1 dismisses the RHP and lands the user on the Report screen's own not-found page — visually identical, so it looks like nothing happened. (ErrorPage/NotFoundPage.tsx:48, inbox/ReportNotFoundGuard.tsx:103-117)
2. Back tap 2 is a genuine no-op. The REPORTS_SPLIT_NAVIGATOR was built with only the REPORT route and no INBOX sidebar beneath it, so canGoBack() is false, and goBack() hits the isAlreadyAtRoot early return and only logs [Navigation] Unable to go back. (Navigation.ts:568-578)

The sidebar is missing because SplitRouter.ts:54 decides "is this the app's initial route?" with rootState.routes.length === 1. The RHP makes that length 2, so on a narrow layout the INBOX sidebar is never injected and the user has nothing to swipe or pop back to.

Investigation details and evidence

Why the central pane is the same invalid report. /r/:reportID/details is a dynamic-suffix route, so getAdaptedStateFromPath.ts:361 branches into getDynamicRouteAdaptedState.ts:112, which strips details, resolves /r/<id>, and inserts it below the RHP with no check that the report exists. This bypasses getAdaptedStateFromPath.ts:288-290, the existing guard that returns a bare sidebar-only split when the report can't be found.

Why tap 1 looks like nothing happened. The details RHP renders through withReportOrNotFound.tsx:149 → <NotFoundPage isReportRelatedPage />. On a small screen with an invalid topmost report, its back handler calls Navigation.dismissModal() — dropping the user onto the exact report the guard just rejected.

Why there is no escape hatch on page 2. The RHP not-found shows a "Go back to home page" link, which works. The Report screen not-found passes shouldShowLink={false} and a bare onBackButtonPress={Navigation.goBack} with no fallback route — so once goBack() no-ops, the page is a dead end. The same pair repeats at lines 174-175.

Reproduction (web dev build, narrow viewport). Tap 1 lands on a second not-found page, confirming the first half:

Deep link	After back tap 1

On web, tap 2 did recover to the Inbox. That is consistent with the root cause: a browser page load is a cold start, navigationRef.isReady() is false during the first render, so rootState is undefined, isInitialRoute is true, and the sidebar is injected. The iOS repro opens a link into an already-running app (warm start), where rootState already holds both routes and the sidebar is skipped. This also explains why only iOS: App is ticked.

Runtime evidence that would raise this to high confidence — on the affected iOS session, look for [Navigation] Unable to go back (Navigation.ts:576) immediately after [ReportScreen] Displaying NotFound Page with reportIDFromPath: 6821704960193694. That pair would confirm the no-op branch directly.

Alternative explanation considered and rejected: that tap 2 hits the still-animating RHP header and re-fires dismissModal(). The tester's deliberate 1-second wait between taps makes a transient animation race unlikely, and it would not explain the missing sidebar.

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

Primary fix — SplitRouter.ts:54: exclude side-modal routes when deciding whether this split navigator is the app's initial route, so an RHP sitting on the root stack no longer suppresses the sidebar. isSideModalNavigator already exists in src/libs/Navigation/helpers/. This restores the LHN beneath any narrow-layout deep link that opens an RHP over a freshly created split navigator, and it fixes the swipe-back gesture too, not just the header arrow.

Defensive fix, worth doing regardless — ReportNotFoundGuard.tsx:110-111 and :174-175: give the back button a fallback route (Navigation.goBack(ROUTES.INBOX)) so it can never be a no-op, and/or drop shouldShowLink={false} so this page offers the same "Go back to home page" escape the RHP not-found already has. A not-found page should never be a dead end.

Regression tests to add: getAdaptedStateFromPath('/r/<id>/details') on a narrow layout must produce a REPORTS_SPLIT_NAVIGATOR containing INBOX, and back from the Report screen not-found must reach the Inbox.

What alternative solutions did you explore? (Optional)

• Make tap 1 skip the invalid report entirely — in NotFoundPage.tsx:48-52, dismiss the modal and continue to home instead of landing on the report the guard just rejected. This makes the reported flow one tap instead of two, which is arguably better UX, but it papers over the missing sidebar and leaves the swipe gesture broken.
• Apply the existence guard to the dynamic-route path — reuse the getReportOrDraftReport check from getAdaptedStateFromPath.ts:288 inside getDynamicRouteAdaptedState. Not recommended as-is: on a cold start Onyx may not be hydrated, so valid reports would also look missing and their /r/<valid>/details deep links would lose the correct back target.
• Relax the isAlreadyAtRoot guard in Navigation.ts — not recommended. The comment at lines 570-574 documents that SignInPage depends on that no-op, and loosening it would mask genuinely broken navigation states.

Related issues

• [Due for payment 2026-09-02] [$250] Web - Go back to home page button is not responsive #98107 — "Go back to home page button is not responsive" on /v/1/1. Same family of stranded-deep-link bugs; its fix (Fix - Web - Go back to home page button is not responsive #98785) added the resetToAppRoot() fallback in Navigation.ts, but that fallback deliberately excludes the case in this issue, so Back button - Does not navigate to LHN Home from "Hmm... it's not here" page` #100415 is not a duplicate.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100415) 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

[melvin-bot]

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

[melvin-bot]

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

[M00rish]

Melvin RCA checks out but solution Touches every narrow deep link with an RHP (all /r//details, /v/), not just invalid reports;
swipe + valid-report back targets shift too

a better apraoach :

In ReportNotFoundGuard, give the back button a fallback to the Inbox and surface the home escape, so an invalid-report page can never strand navigation.

App/src/pages/inbox/ReportNotFoundGuard.tsx

Lines 110 to 111 in c53cb91

	onBackButtonPress={Navigation.goBack}
	shouldShowLink={false}

could draft a proposal if needed.

[danielamodu]

Proposal

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

When navigating directly to an invalid report details URL (e.g. /r/<invalid_reportID>/details) on iOS or narrow layouts, the "Hmm... it's not here" page is displayed. Tapping Back once dismisses the details modal, but tapping Back a second time on the underlying Report not-found screen fails to navigate back to the LHN Home page, stranding the user on the "Hmm... it's not here" page.

What is the root cause of that problem?

In src/pages/inbox/ReportNotFoundGuard.tsx (both the outer guard at lines 105-115 and the inner guard at lines 170-180), FullPageNotFoundView is rendered with:

• onBackButtonPress={Navigation.goBack} (no fallback route passed).
• shouldShowLink={false} (disabling the "Go back to home page" escape link).

When a user opens a deep link such as /r/:reportID/details:

1. The details page opens in an RHP over the base ReportScreen.
2. On the first Back tap, NotFoundPage (via isReportRelatedPage and invalid report detection) calls Navigation.dismissModal(), which dismisses the details RHP.
3. This exposes the base ReportScreen, where ReportNotFoundGuard renders its own FullPageNotFoundView.
4. On the second Back tap, Navigation.goBack is called with no arguments. In src/libs/Navigation/Navigation.ts (lines 553-570), goBack checks if there is any preceding route in the navigation stack to pop. Because the app was opened via a direct deep link, there is nothing left to pop. Without a backToRoute fallback (such as ROUTES.HOME), goBack() early-returns as a no-op with [Navigation] Unable to go back.
5. Combined with shouldShowLink={false}, the page has no functional back target and no escape link, stranding the user.

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

In src/pages/inbox/ReportNotFoundGuard.tsx:

1. Update onBackButtonPress in both ReportNotFoundGuard (line 110) and ReportNotFoundInnerGuard (line 174) to pass ROUTES.HOME as the fallback route:

onBackButtonPress={() => Navigation.goBack(ROUTES.HOME)}

(or Navigation.goBackToHome).

2. Remove shouldShowLink={false} (or provide onLinkPress={() => Navigation.goBack(ROUTES.HOME)}) so the standard "Go back to home page" link is also available on desktop/tablet layouts where the back button is hidden.

When a prior screen exists in the stack, Navigation.goBack pops back normally; when the user arrived via a direct deep link with an empty back-stack, it safely falls back to ROUTES.HOME (the LHN Home page).

What alternative solutions did you explore? (Optional)

1. Modifying SplitRouter.ts: Altering isSideModalNavigator checks in the split navigator changes back-stack generation for all deep links containing an RHP (including valid reports), introducing broader navigation regression risks.
2. Dismissing straight to home in NotFoundPage.tsx: Changing the RHP not-found behavior skips the second screen, but leaves direct visits to /r/<invalid_id> stranded with the same bug.

[melvin-bot]

📣 @danielamodu! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[danielamodu]

Contributor details
My Expensify account email: theamebonetwork@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01a4de9b3275e3f4c5

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!