Web - Go back to home page button is not responsive

[nlemma]

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.4.51-1
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://github.com/Expensify/Expensify/issues/467825
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: macOS Tahoe 26.5 - Chrome

Action Performed:

1. Go to https://staging.new.expensify.com/v/1/1
2. Click Go back to home page.

Expected Result:

Home page will open.

Actual Result:

Go back to home page button is not responsive.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7216601_1784913623742.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022086546509644493069
• Upwork Job ID: 2086546509644493069
• Last Price Increase: 2026-08-09

[MelvinBot]

Proposal

What is the root cause of that problem?

/v/1/1 is the magic-link validation route (VALIDATE_LOGIN: 'v/:accountID/:validateCode'), so accountID=1, validateCode=1. Since 1 fails isValidValidateCode, ValidateLoginPage renders ValidateCodeModal, which shows the "Hmm... it's not here" page (FullPageNotFoundView) with the Go back to home page link.

That link is the problem. ValidateCodeModal overrides the link's handler with a bare Navigation.goBack() at ValidateCodeModal.tsx:49-51 — with no fallback route. When you open /v/1/1 directly (fresh tab, no in-app navigation history), goBack() hits the guard at Navigation.ts:560-563: canGoBack() is false, so it logs [Navigation] Unable to go back and returns without navigating. The button appears unresponsive.

This overrides the component's own default, which already does the right thing — FullPageNotFoundView.tsx:84 defaults onLinkPress to Navigation.goBackToHome(), which passes ROUTES.HOME as a fallback and therefore works with no history.

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

Give the link a Home fallback so it navigates even when there's no history. In ValidateCodeModal.tsx, either:

• Remove the onLinkPress override entirely so FullPageNotFoundView's default Navigation.goBackToHome() is used (matches the "Go back to home page" label), or
• Pass a fallback: onLinkPress={() => Navigation.goBack(ROUTES.HOME)}.

Note the header back button (narrow layout) uses the same fallback-less default, so the fix should ensure navigation to Home is guaranteed rather than relying on history.

What alternative solutions did you explore? (Optional)

None needed — the default handler in the same component tree already demonstrates the correct pattern.

Verification (web) — confirmed reproducible

Navigated directly to /v/1/1 on dev NewDot (signed in), which showed the "Hmm... it's not here" page with the Go back to home page link. Clicking the link did nothing: the URL stayed at /v/1/1, the accessibility snapshot was unchanged, before/after screenshots were pixel-identical, and the Home-only "Search" button never appeared.

Not-found page for /v/1/1 before clicking the link

Same not-found page after clicking Go back to home page, unchanged

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/blob/50938ee687c87107298f20d36e24a6e300f7e0d2/src/components/ValidateCode/ValidateCodeModal.tsx#L49-L51) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022086546509644493069