[$250] hat-Top left arrow on hmm not here page is not responsive.

[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: V9.3.79-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90453
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Chat Report View

Action Performed:

1. Launch app
2. Open a chat
3. Send a message - https://staging.new.expensify.com/workspaces/A9C264093488648C/tags
4. Tap on the link
5. Tap top left arrow

Expected Result:

Top left arrow on hmm not here page must be responsive.

Actual Result:

Top left arrow on hmm not here page 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

Bug7160710_1779457605296.Screenrecorder-2026-05-22-19-13-12-8.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057825810998539634
• Upwork Job ID: 2057825810998539634
• Last Price Increase: 2026-05-22

[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/4e2ba83768fd542cb715deada8f53a16500aeac65e12c023f43aba5dac6d7b90

[MelvinBot]

Proposal

What is the root cause of that problem?

When the user taps a workspace link they don't have access to (e.g., /workspaces/{policyID}/tags), AccessOrNotFoundWrapper renders a PageNotFoundFallback ("Hmm… it's not here"). The back button calls goBackFromWorkspaceSettingPages(), which checks whether the previous route is the inbox. When the user came from a chat, isPreviousInbox is true, so it calls Navigation.dismissModal().

dismissModal() dispatches a DISMISS_MODAL action, which is handled by handleDismissModalAction. This function checks whether the topmost route is in MODAL_ROUTES_TO_DISMISS. NAVIGATORS.WORKSPACE_NAVIGATOR is not in that set, so the handler logs [Navigation] dismissModal failed because there is no modal stack to dismiss and returns null — nothing happens, and the back button appears unresponsive.

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

Add NAVIGATORS.WORKSPACE_NAVIGATOR to the MODAL_ROUTES_TO_DISMISS set in GetStateForActionHandlers.ts. This allows dismissModal() to pop the workspace navigator off the root stack and return the user to the chat they came from.

What alternative solutions did you explore? (Optional)

An alternative would be to change goBackFromWorkspaceSettingPages to use Navigation.goBack() or StackActions.pop() instead of dismissModal() when isPreviousInbox is true. However, dismissModal is the correct semantic action here (dismiss the workspace modal and return to the underlying inbox), so the better fix is to allow it to work for the workspace navigator.

Investigation details

Call chain:

1. User taps back arrow → PageNotFoundFallback.onBackButtonPress fires
2. isPolicyNotAccessible is true → calls goBackFromWorkspaceSettingPages()
3. Previous route is REPORTS_SPLIT_NAVIGATOR (the chat) → calls Navigation.dismissModal()
4. DISMISS_MODAL action reaches handleDismissModalAction() → topmost route is WorkspaceNavigator which is not in MODAL_ROUTES_TO_DISMISS → returns null

Related issue: #89259 describes similar inconsistent back navigation on "Hmm not here" pages.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

When a user taps a link in a chat message that resolves to the "Hmm, not here" (NotFoundPage) screen, the back arrow in the top-left header does not respond to taps and has no visible effect.

What is the root cause of that problem?

NotFoundPage passes onBackButtonPress to FullPageNotFoundView, which ultimately renders a HeaderWithBackButton. The default onBackButtonPress is () => Navigation.goBack() — called with no fallback route. Inside Navigation.goBack(), when there is no prior navigation history (the user arrived via a deep link that resolved directly to the NOT_FOUND screen), navigationRef.current?.canGoBack() returns false, so the function logs "Unable to go back" and silently exits without navigating anywhere. The back arrow appears to render fine but produces no navigation effect because there is nothing in the stack to pop back to.

The onLinkPress prop already handles this correctly: when isOnGenericErrorScreen is true (i.e. route.name === SCREENS.NOT_FOUND), it is overridden to call Navigation.goBack(ROUTES.HOME), which passes a fallback route so the user lands on the home screen. However, this same ROUTES.HOME fallback is never applied to onBackButtonPress.

App/src/pages/ErrorPage/NotFoundPage.tsx

Lines 38 to 52 in 660202b

	onBackButtonPress={() => {
	if (!isReportRelatedPage || !isSmallScreenWidth) {
	onBackButtonPress();
	return;
	}
	// detect the report is invalid
	if (topmostReportId && (!report || report.errorFields?.notFound)) {
	Navigation.dismissModal();
	return;
	}
	onBackButtonPress();
	}}
	{...fullPageNotFoundViewProps}
	onLinkPress={isOnGenericErrorScreen ? () => Navigation.goBack(ROUTES.HOME) : fullPageNotFoundViewProps.onLinkPress}

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

In NotFoundPage.tsx, mirror the same logic that is already applied to onLinkPress for onBackButtonPress: when isOnGenericErrorScreen is true, call Navigation.goBack(ROUTES.HOME) instead of the default Navigation.goBack(). Concretely, the onBackButtonPress prop passed to FullPageNotFoundView should be conditionally overridden — exactly as onLinkPress is overridden two lines below — so that tapping the back arrow on the generic SCREENS.NOT_FOUND screen always falls back to the home route rather than silently doing nothing when there is no stack history to pop.

App/src/pages/ErrorPage/NotFoundPage.tsx

Lines 20 to 56 in 660202b

	function NotFoundPage({onBackButtonPress = () => Navigation.goBack(), isReportRelatedPage, shouldShowOfflineIndicator, ...fullPageNotFoundViewProps}: NotFoundPageProps) {
	// We need to use isSmallScreenWidth instead of shouldUseNarrowLayout to go back to the not found page on large screens and to the home page on small screen
	// eslint-disable-next-line rulesdir/prefer-shouldUseNarrowLayout-instead-of-isSmallScreenWidth
	const {isSmallScreenWidth} = useResponsiveLayout();
	const topmostReportId = Navigation.getTopmostReportId();
	const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${topmostReportId}`);
	const route = useRoute();
	const isOnGenericErrorScreen = route.name === SCREENS.NOT_FOUND;
	useAbsentPageSpan();
	return (
	<ScreenWrapper
	testID="NotFoundPage"
	shouldShowOfflineIndicator={shouldShowOfflineIndicator}
	>
	<FullPageNotFoundView
	shouldShow
	onBackButtonPress={() => {
	if (!isReportRelatedPage || !isSmallScreenWidth) {
	onBackButtonPress();
	return;
	}
	// detect the report is invalid
	if (topmostReportId && (!report || report.errorFields?.notFound)) {
	Navigation.dismissModal();
	return;
	}
	onBackButtonPress();
	}}
	{...fullPageNotFoundViewProps}
	onLinkPress={isOnGenericErrorScreen ? () => Navigation.goBack(ROUTES.HOME) : fullPageNotFoundViewProps.onLinkPress}
	/>
	</ScreenWrapper>
	);
	}

What alternative solutions did you explore? (Optional)

N/A

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When a user navigates to a URL like /workspaces/.../tags that doesn't exist or is inaccessible, the "Not Found" (hmm not here) page is rendered. The back arrow in the top-left is unresponsive because the NotFoundPage component likely renders without a proper navigation handler or the goBack action is not wired correctly when arriving from an in-app link on Android/Web platforms.

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

The NotFoundPage should use Navigation.goBack() (or Navigation.dismissModal() as a fallback) when the back button is pressed. I'd look at src/pages/ErrorPage/NotFoundPage.tsx and ensure the back arrow calls navigation correctly:

- onBackButtonPress={() => Navigation.goBack()}
+ onBackButtonPress={() => {
+   if (Navigation.canGoBack()) {
+     Navigation.goBack();
+   } else {
+     Navigation.navigate(ROUTES.HOME);
+   }
+ }}

This ensures that if there's no history to go back to (e.g., arrived via deep link), the user is still navigated away from the not-found page to a valid route instead of the button doing nothing.

What alternative solutions did you explore?

I considered always navigating to ROUTES.HOME directly, but that would break the expected back-navigation UX when there is a valid back stack. The canGoBack() guard handles both cases cleanly.

[kamronbek04]

Proposal

What is the root cause of that problem?

Tracing the repro: tapping the /workspaces/A9C264093488648C/tags link from a chat deep-links into WorkspaceTagsPage, which wraps its content in
AccessOrNotFoundWrapper. The target policy isn't in the affected
user's account, so isPolicyNotAccessible resolves to true and the wrapper renders
PageNotFoundFallback. That fallback wires the header's back arrow to
goBackFromWorkspaceSettingPages() when the policy is inaccessible.

goBackFromWorkspaceSettingPages looks at the
second-to-last entry of the root navigator. When the user came from a chat, that route resolves to TAB_NAVIGATOR with REPORTS_SPLIT_NAVIGATOR as its active tab, so
isPreviousInbox is true and the helper dispatches Navigation.dismissModal().

The problem is that the topmost route at this point is WORKSPACE_SPLIT_NAVIGATOR — pushed onto the root stack by the deep-link, not a modal.
handleDismissModalAction only
pops the top route when its name appears in
MODAL_ROUTES_TO_DISMISS. That
set contains the right-hand modal navigator, onboarding/feature-training modals, NOT_FOUND, attachment screens, etc. — but not WORKSPACE_SPLIT_NAVIGATOR. The handler bails
with the log line dismissModal failed because there is no modal stack to dismiss and returns null. The navigation state doesn't change, the press visibly does nothing,
and the user is stuck.

The helper was originally written assuming workspace settings are reached from the Workspaces tab (where workspace screens sit inside a split navigator next to the sidebar)
or from the RHP modal (where dismissModal works). The chat → deep link path produces a third stack shape the helper doesn't recognise, so its "previous was Inbox" branch
picks the wrong dispatcher. Both Android app and Windows Chrome reproduce it because the failure is in the router, not the platform.

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

Make the helper branch on the current stack shape, not just the previous route. dismissModal is only correct when the topmost root route is actually dismissable; otherwise
a plain Navigation.goBack() on the root stack will pop the deep-linked WORKSPACE_SPLIT_NAVIGATOR and land the user back on the chat (which is where dismissModal was
trying to send them anyway).

 function goBackFromWorkspaceSettingPages() {
     const rootState = navigationRef.getRootState() as State<RootNavigatorParamList>;
+    const lastRoute = rootState.routes.at(-1);
     const secondToLastRoute = rootState.routes.at(-2);

     const isPreviousInbox = getActiveTabName(secondToLastRoute) === NAVIGATORS.REPORTS_SPLIT_NAVIGATOR;

     if (isPreviousInbox) {
-        Navigation.dismissModal();
+        if (lastRoute?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR) {
+            Navigation.dismissModal();
+        } else {
+            Navigation.goBack();
+        }
     } else {
         Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
     }
 }

I prefer the narrow RIGHT_MODAL_NAVIGATOR check over reusing MODAL_ROUTES_TO_DISMISS directly: the latter is an internal router detail and would couple this helper to an
evolving list. The only modal the workspace settings flows realistically sit inside on this path is the RHP — onboarding/feature-training/share modals don't host workspace
settings screens.

An alternative I considered was teaching handleDismissModalAction to fall through to a stack pop when the top route isn't a modal. I rejected it: dismissModal is called
from many places that rely on the noop+log behaviour when there's nothing to dismiss, and silently turning it into a generic pop would risk breaking those call sites. Fixing
the caller keeps the blast radius confined to this one helper.

What this change does not touch: the else branch, the useEffect at
AccessOrNotFoundWrapper.tsx#L224-L229 that strips WORKSPACE.INITIAL
from history, or any other consumer of Navigation.dismissModal. Reviewers should confirm that the existing "Workspaces tab → workspace settings → back" path (where the
previous route is the workspaces list and isPreviousInbox is false) still routes through the goBack(WORKSPACES_LIST) branch unchanged.

Other call sites of Navigation.dismissModal() invoked from "not-found"-style back handlers in non-modal stacks may carry the same latent bug — e.g. handlers wired up from
screens reached by deep-link rather than from an RHP push. Out of scope for this fix but a candidate for an audit pass.

Verification: From a chat report, send and tap https://staging.new.expensify.com/workspaces/<a-policy-id-not-on-your-account>/tags. The "Hmm... it's not here" page
should render, the top-left back arrow should be tappable, and pressing it should return to the chat thread the link was sent from. Re-verify the Workspaces tab → tags entry
path still returns to the workspaces list, and that RHP-hosted not-found screens still close the RHP rather than popping the underlying stack.

GitHub paste tip: use "Raw" copy button on a gist or paste source-mode in issue comment. Copying from rendered output strips markdown syntax.

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

When a chat URL points to a workspace the user doesn't have access to, the top-left arrow on the "Hmm... it's not here" page calls goBackFromWorkspaceSettingPages, which dispatches Navigation.dismissModal():

https://github.com/Expensify/App/blob/main/src/libs/Navigation/helpers/goBackFromWorkspaceSettingPages.ts#L11-L22

const isPreviousInbox = getActiveTabName(secondToLastRoute) === NAVIGATORS.REPORTS_SPLIT_NAVIGATOR;
if (isPreviousInbox) {
    Navigation.dismissModal();
} else {
    Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
}

This is fine when the user reached the workspace through a modal route (the dispatch from Settings → Workspaces → click workspace opens it in a RIGHT_MODAL_NAVIGATOR). But the repro path is different: clicking the workspace URL in chat is handled by linkTo, which pushes the workspace navigator inside the existing tab rather than as a modal. The router state at that point is:

REPORTS_SPLIT_NAVIGATOR  ← second-to-last (matches isPreviousInbox)
WORKSPACE_NAVIGATOR      ← topmost
  └─ WORKSPACE_SPLIT_NAVIGATOR (showing NotFound fallback)

isPreviousInbox is true (the second-to-last is the inbox tab), so the branch fires Navigation.dismissModal(). But the workspace stack isn't a modal — dismissModal has nothing to dismiss, so it returns silently. The user sees the back-arrow press do nothing.

The same code path works for Settings → Workspaces → click workspace because that is a modal stack — there, dismissModal correctly pops the whole stack.

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

goBackFromWorkspaceSettingPages needs to distinguish "workspace opened as modal" from "workspace opened in-tab". When it isn't a modal, plain Navigation.goBack() does the right thing — it pops the workspace navigator and returns to the report.

  function goBackFromWorkspaceSettingPages() {
      const rootState = navigationRef.getRootState() as State<RootNavigatorParamList>;
      const secondToLastRoute = rootState.routes.at(-2);

      const isPreviousInbox = getActiveTabName(secondToLastRoute) === NAVIGATORS.REPORTS_SPLIT_NAVIGATOR;
+     const topmostRoute = rootState.routes.at(-1);
+     const isTopmostModal = topmostRoute?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;

      if (isPreviousInbox) {
-         Navigation.dismissModal();
+         if (isTopmostModal) {
+             Navigation.dismissModal();
+         } else {
+             // Workspace was pushed into the tab (e.g. via in-chat URL), not as a modal.
+             // dismissModal is a no-op here; goBack pops the workspace navigator correctly.
+             Navigation.goBack();
+         }
      } else {
          Navigation.goBack(ROUTES.WORKSPACES_LIST.route);
      }
  }

After this:

• Settings → Workspaces → click workspace (existing modal flow): topmost is RIGHT_MODAL_NAVIGATOR → dismissModal() runs as before. No regression.
• Chat → click workspace URL → NotFound → back arrow (the bug): topmost is the workspace navigator pushed in-tab → goBack() pops it, the user lands back in the chat where the link was clicked.

[lxyct825-ops]

Proposal

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

hat-Top left arrow on hmm not here page is not responsive.

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.