LHN - Left navigation bar is replaced by back button after returning to home page

[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.91-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91856
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Send an invalid workspace link to any chat (eg, https://staging.new.expensify.com/workspaces/720242C9C25F7349/overview)
3. Click on the link.
4. Click Go back to home page.

Expected Result:

Left navigation bar will appear after returning to home page.

Actual Result:

Left navigation bar is replaced by back button after returning to 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

Bug7169328_1780383940471.1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @borys3kk

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

[melvin-bot]

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

[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

Problem

After viewing an invalid workspace link (a "Hmm... it's not here" page) and clicking Go back to home page, the left navigation bar (LHN) on wide‑screen web is replaced by a lone back button.

This is the inverse of the bug that #91856 fixed (#91831 — "back button not showing on the not‑here page"). That PR traded one stacking bug for another, which is why this only reproduces on staging (not production).

Root Cause

#91856 removed the static zIndex: 1 from the tabNavigatorBarContainer style and instead applies it inline only when !isBlockingViewVisible at TabNavigatorBar.tsx:86.

isBlockingViewVisible is true whenever the route‑key set is non‑empty (FullScreenBlockingViewContextProvider.tsx:49). Keys are added/removed by ForceFullScreenView on mount/unmount only (ForceFullScreenView/index.tsx:13-21).

The break: on wide layout, Go back to home page → Navigation.goBackToHome() (Navigation.ts:614) → goBack(ROUTES.HOME) → goUp dispatches TabActions.jumpTo(HOME) (Navigation.ts:469). jumpTo only switches the active tab — it does not unmount the Workspaces tab's stack. The invalid‑workspace screen stays mounted, so removeRouteKey never fires, isBlockingViewVisible stays true, and the tab bar never regains zIndex: 1.

Meanwhile the not‑here page's wrapper forcedBlockingViewContainer is a position: fixed, opaque, full‑viewport overlay (styles/index.ts:2768) containing the HeaderWithBackButton. With the tab bar's zIndex gone and the workspace screen still mounted, that stale overlay keeps painting over the LHN — so the user sees only a back button.

This is wide‑screen‑web specific because the conditional zIndex lives in the wide‑layout branch and the overlay uses position: fixed (web), matching the only platforms checked (Windows Chrome, macOS Chrome/Safari).

Solution

Proper fix — tie the route key to focus, not just mount, in ForceFullScreenView/index.tsx. Add useIsFocused() and gate the effect on it:

const isFocused = useIsFocused();
useEffect(() => {
    if (!shouldForceFullScreen || !isFocused) {
        return;
    }
    addRouteKey(route.key);
    return () => removeRouteKey(route.key);
}, [addRouteKey, removeRouteKey, route.key, shouldForceFullScreen, isFocused]);

When the workspace screen blurs after jumpTo(HOME), useIsFocused() flips to false, the cleanup removes the key, isBlockingViewVisible becomes false, and the tab bar regains zIndex: 1 so the LHN paints above the (now blurred) overlay.

Fast mitigation (if a fix can't land before the deploy) — revert #91856 to restore the static zIndex: 1. Note this reintroduces #91831.

Evidence chain

1. Open invalid /workspaces/<id>/overview → FullPageNotFoundView with shouldForceFullScreen → ForceFullScreenView calls addRouteKey → isBlockingViewVisible = true → tab bar drops zIndex (the intended Back button is not showing on "Hmm... it's not here" page #91856 behavior, so the not‑here back button shows).
2. Click Go back to home page → goBackToHome() → goBack(ROUTES.HOME) → goUp → TabActions.jumpTo(HOME). HOME and the workspace route live under the same TAB_NAVIGATOR, so this only switches tabs; the workspace screen stays mounted (no unmountOnBlur).
3. ForceFullScreenView cleanup never runs → routeKeys.size > 0 stays true → isBlockingViewVisible stuck true → tab bar never regains zIndex: 1.
4. The position: fixed opaque forcedBlockingViewContainer (with HeaderWithBackButton) keeps overlaying the LHN region → "LHN replaced by a back button."

Two independent investigations agreed on this chain (high confidence). The static stacking analysis is decisive; no production logs needed.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[lakchote]

Not a blocker, minor UI bug.