[$250] Reports- LHN dims after clicking report link and returning via back button on report view

[mitarachim]

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.2.65-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/test-runs/TR-2203/folder/13176670/41237099/1041757916
Email or phone of affected tester (no customers): sdjniosdjojsdonjs3@gmail.com
Issue reported by: Applause Internal Team
Device used: Mac 26.1 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a expense.
4. Open the expense report.
5. Click Report field.
6. Click Create report.
7. Go to Reports > Expenses.
8. Click on the report link in "moved expense to" system message.
9. Click app back button.

Expected Result:

LHN on Reports will not dim.

Actual Result:

LHN on Reports dims after clicking report link and returning via back button on report view

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7014504_1764210854303.2.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021993889450872904109
• Upwork Job ID: 1993889450872904109
• Last Price Increase: 2025-11-27

Issue Owner

Current Issue Owner: @dominictb

[melvin-bot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[melvin-bot]

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

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2025-11-27 10:03:01 UTC.

Proposal

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

When clicking a report link from a "moved expense to" system message in the Reports > Expenses view and then navigating back using the app back button, the Left Hand Navigation (LHN) on Reports incorrectly remains dimmed. The LHN should not be dimmed when returning to the Reports list view.

What is the root cause of that problem?

The root cause appears to be related to how the navigation state is managed when clicking report links from system messages. When a report link is clicked:

1. The link is handled by openLink() in Link.ts, which calls Navigation.navigate() to navigate to the report
2. The navigation pushes a new report screen onto the ReportsSplitNavigator stack
3. When navigating back, the navigation state may not be properly reset, causing the overlay from RightModalNavigator to remain visible

The overlay that dims the LHN is controlled by the RightModalNavigator component, which always renders an overlay when !shouldUseNarrowLayout. The overlay's visibility/opacity is controlled by card animation progress. If the navigation state isn't properly cleaned up when going back, the overlay may remain visible even though no RHP screens are actually open.

Additionally, the report links in "moved expense to" messages have target='_blank' attributes, which might affect how the navigation is handled. While openLink() should handle internal links correctly, there may be edge cases where the navigation state isn't properly managed.

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

The root cause is that the overlay in RightModalNavigator is always rendered when !shouldUseNarrowLayout, regardless of whether there are any RHP screens in the stack. While the overlay's opacity is controlled by card animation progress (which should be 0 when there are no screens), there may be edge cases where the progress isn't properly reset, causing the overlay to remain visible and dim the LHN.

Fix:

1. Conditionally render overlay based on RHP visibility and screen presence: Modified RightModalNavigator to only render the overlay when:

   • The RightModalNavigator is actually visible (is the topmost route or after the last full screen route)
   • The RHP navigator has actual screens in its stack

2. Prevent unnecessary overlay rendering: By conditionally rendering the overlay only when both conditions are met, we ensure that the overlay is never visible when there are no RHP screens or when the RHP is not visible, preventing the LHN from being dimmed incorrectly.

Code Changes:

File: App/src/libs/Navigation/AppNavigator/Navigators/RightModalNavigator.tsx

1. Added imports:

import useRootNavigationState from '@hooks/useRootNavigationState';
import {isFullScreenName} from '@libs/Navigation/helpers/isNavigatorName';

2. Added logic to check if overlay should be shown:

// Check if RightModalNavigator is actually visible (is the topmost route or after the last full screen)
// and has actual RHP screens in its stack
// Only render the overlay when RHP is visible AND has screens to prevent dimming when navigating back from report links
const shouldShowOverlay = useRootNavigationState((state) => {
    if (!state) {
        return false;
    }
    const lastFullScreenRouteIndex = state.routes.findLastIndex((route) => isFullScreenName(route.name));
    const lastRHPRouteIndex = state.routes.findLastIndex((route) => route.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR);

    if (lastRHPRouteIndex === -1) {
        return false;
    }

    // RHP is visible if:
    // 1. There's no full screen route and RHP is the topmost route, OR
    // 2. RHP is after the last full screen route
    const isRHPVisible =
        (lastFullScreenRouteIndex === -1 && lastRHPRouteIndex === state.routes.length - 1) ||
        (lastFullScreenRouteIndex !== -1 && lastFullScreenRouteIndex < lastRHPRouteIndex);

    if (!isRHPVisible) {
        return false;
    }

    // Check if the RHP navigator has actual screens in its stack
    const rhpRoute = state.routes[lastRHPRouteIndex];
    const hasRHPScreens = rhpRoute?.state?.routes && rhpRoute.state.routes.length > 0;

    return hasRHPScreens;
});

3. Updated overlay rendering condition:

{!shouldUseNarrowLayout && shouldShowOverlay && <Overlay onPress={handleOverlayPress} />}

The fix ensures that:

• The overlay only renders when the RightModalNavigator is visible AND has actual RHP screens in its stack
• When navigating back from a report link, if there are no RHP screens or the RHP is not visible, the overlay won't be rendered, preventing the LHN from dimming
• The navigation state is properly checked using root navigation state before rendering the overlay

What alternative solutions did you explore? (Optional)

N/A

Demo

Screen.Recording.2025-11-27.at.3.03.57.PM.mov

[lorretheboy]

🚨 Edited by proposal-police: This proposal was edited at 2025-11-27 15:29:45 UTC.

Proposal

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

LHN on Reports dims after clicking report link and returning via back button on report view

What is the root cause of that problem?

The overlay is ALWAYS rendered when !shouldUseNarrowLayout, regardless of whether there were any RHP screens visible.

App/src/libs/Navigation/AppNavigator/Navigators/RightModalNavigator.tsx

Line 71 in 5448e84

{!shouldUseNarrowLayout && <Overlay onPress={handleOverlayPress} />}

We control the overlay here by React Navigation's card animation progress

App/src/libs/Navigation/AppNavigator/Navigators/Overlay/BaseOverlay.tsx

Line 28 in 5448e84

const {current} = useCardAnimation();

App/src/styles/index.ts

Lines 5636 to 5640 in 000c059

	opacity: progress.interpolate({
	inputRange: [0, 1],
	outputRange: [0, variables.overlayOpacity],
	extrapolate: 'clamp',
	}),

But in this case the progress value is not 0 --> The overlay remains rendered with non-zero opacity

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

We should use useIsFocused to determine if the RHP navigator is actually focused/visible, rather than relying on the card animation progress

    const isFocused = useIsFocused();
.
.
   {!shouldUseNarrowLayout && isFocused && <Overlay onPress={handleOverlayPress} />}

App/src/libs/Navigation/AppNavigator/Navigators/RightModalNavigator.tsx

Line 71 in 5448e84

{!shouldUseNarrowLayout && <Overlay onPress={handleOverlayPress} />}

Can do similar to PublicRightModalNavigator as well if needed

What alternative solutions did you explore? (Optional)

Don't rely on animation progress to hide the overlay. Instead, conditionally render the overlay only when it should actually be visible

    const hasScreens = useRootNavigationState((state) => {
        if (!state) {
            return false;
        }
        const topmostRoute = state.routes[state.index];
        const isRHPTopmost = topmostRoute?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;
        const hasRHPScreens = (topmostRoute?.state?.routes?.length ?? 0) > 0;
        return isRHPTopmost && hasRHPScreens;
    });

.
.

   {!shouldUseNarrowLayout && hasScreens && <Overlay onPress={handleOverlayPress} />}

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @lorretheboy Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[Burhan-Rashid]

Proposal

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

Reports- LHN dims after clicking report link and returning via back button on report view

What is the root cause of that problem?

When we click on any link, we use this function openLink which calls Navigation.navigate() but doesn't close the RHP.

App/src/libs/actions/Link.ts

Line 189 in a414faa

function openLink(href: string, environmentURL: string, isAttachment = false) {

App/src/libs/actions/Link.ts

Lines 200 to 216 in c13d47d

	if (hasExpensifyOrigin && href.indexOf('newdotreport?reportID=') > -1) {
	const reportID = href.split('newdotreport?reportID=').pop();
	const reportRoute = ROUTES.REPORT_WITH_ID.getRoute(reportID);
	Navigation.navigate(reportRoute);
	return;
	}
	// If we are handling a New Expensify link then we will assume this should be opened by the app internally. This ensures that the links are opened internally via react-navigation
	// instead of in a new tab or with a page refresh (which is the default behavior of an anchor tag)
	if (internalNewExpensifyPath && hasSameOrigin) {
	if (isAnonymousUser() && !canAnonymousUserAccessRoute(internalNewExpensifyPath)) {
	signOutAndRedirectToSignIn();
	return;
	}
	Navigation.navigate(internalNewExpensifyPath as Route);
	return;
	}

It navigates the user to a new route but RightModalNavigator is still present in navigation stack, because we never poped it out of the navigation stack. That is why when user presses the back button, we again see the overlay from RightModalNavigator because it is always rendered when shouldUseNarrowLayout is false.

App/src/libs/Navigation/AppNavigator/Navigators/RightModalNavigator.tsx

Line 71 in a414faa

{!shouldUseNarrowLayout && <Overlay onPress={handleOverlayPress} />}

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

We can create a new util function, which checks if the new route that we are opening via openLink function will open in RHP or not and based on that, we can decide whether to close the RHP or not in openLink function. For that we need the following changes:
Util function:

/**
 * Check if a route will navigate to a screen in the RightModalNavigator
 */
function willNavigateToRHP(route: Route): boolean {
    try {
        const state = getStateFromPath(route);
        if (!state) {
            return false;
        }
        // Check if the last route in the state is the RightModalNavigator
        const lastRoute = state?.routes?.at(-1);
        return lastRoute?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;
    } catch {
        // If parsing fails, assume it's not an RHP route
        return false;
    }
}

And use this function here:

App/src/libs/actions/Link.ts

Line 194 in c13d47d

    // Check if RHP is currently open
    const currentState = navigationRef.getRootState();
    const isRHPOpen = currentState?.routes?.at(-1)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;

    // Check if the destination route will also open in RHP
    const willOpenInRHP = willNavigateToRHP(internalNewExpensifyPath as Route);

And finally before navigating to the new route, close the RHP based on this condition here:

App/src/libs/actions/Link.ts

Lines 202 to 203 in c13d47d

	const reportRoute = ROUTES.REPORT_WITH_ID.getRoute(reportID);
	Navigation.navigate(reportRoute);

       if (isRHPOpen && !willOpenInRHP) {
            Navigation.closeRHPFlow();
        }
        Navigation.navigate(reportRoute);
...

And here:

App/src/libs/actions/Link.ts

Line 214 in c13d47d

Navigation.navigate(internalNewExpensifyPath as Route);

 if (isRHPOpen && !willOpenInRHP) {
            Navigation.closeRHPFlow();
        }
        Navigation.navigate(internalNewExpensifyPath as Route);
...

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.