Reports - Clicking 'New messages' button breaks browser back navigation in report view

[izarutskaya]

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.24-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @TaduJR
Slack conversation (hyperlinked to channel name): expensify_open_source

Action Performed:

1. Create Duplicate Expense
2. Open the report
3. Click Review Duplicate
4. Click on Keep this one on one of the expenses
5. Select the merchant to keep and Confirm
6. Go to Reports
7. Open the report your created
8. Scroll down and scroll up so the "New messages" button appears
9. Click the "New messages" button
10. Press the browser Back button

Expected Result:

Pressing Back should return the user to the Reports list view.

Actual Result:

The current report reloads instead of returning to the Reports list.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

Screen.Recording.2025-10-07.at.13.24.16.1.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @garrettmknight (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.

[TaduJR]

Proposal

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

When users click the "New messages" button in a report and then use the browser's back button, the current report reloads instead of returning to the Reports list view.

What is the root cause of that problem?

The root cause is in the scrollToBottomAndMarkReportAsRead function in src/pages/home/report/ReportActionsList.tsx. When the "New messages" button is clicked and the report doesn't have the newest report action loaded (!hasNewestReportAction), the function calls Navigation.navigate() to refresh the report data.

App/src/pages/home/report/ReportActionsList.tsx

Lines 530 to 550 in b76a740

	const scrollToBottomAndMarkReportAsRead = useCallback(() => {
	setIsFloatingMessageCounterVisible(false);
	if (!hasNewestReportAction) {
	if (isSearchTopmostFullScreenRoute()) {
	if (Navigation.getReportRHPActiveRoute()) {
	Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: report.reportID}));
	} else {
	Navigation.navigate(ROUTES.SEARCH_MONEY_REQUEST_REPORT.getRoute({reportID: report.reportID}));
	}
	} else {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID));
	}
	openReport(report.reportID);
	reportScrollManager.scrollToBottom();
	return;
	}
	reportScrollManager.scrollToBottom();
	readActionSkipped.current = false;
	readNewestAction(report.reportID);
	}, [setIsFloatingMessageCounterVisible, hasNewestReportAction, reportScrollManager, report.reportID]);

By default, Navigation.navigate() uses the PUSH action (confirmed in src/libs/Navigation/helpers/linkTo/index.ts:119), which adds a new entry to the browser's navigation history stack. This creates a history like:

1. Reports list
2. Report (initial view)
3. Report (after clicking "New messages") ← current page

When the user presses the browser Back button, it navigates to entry 2 (the same report), causing the report to reload instead of returning to the Reports list (1).

The function also loses the backTo parameter during navigation, which breaks the navigation chain for programmatic back navigation.

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

We should make two changes to fix the browser back button behavior:

Change 1: Fix scrollToBottomAndMarkReportAsRead in src/pages/home/report/ReportActionsList.tsx (lines 530-551)

1. Extract the backTo parameter from the route to preserve the navigation chain
2. Add {forceReplace: true} option to all three Navigation.navigate() calls to replace the current history entry instead of pushing a new one
3. Additionally we could also pass the backTo parameter to all route builders
4. Update the useCallback dependency array to include route?.params?.backTo

const scrollToBottomAndMarkReportAsRead = useCallback(() => {
    setIsFloatingMessageCounterVisible(false);

    if (!hasNewestReportAction) {
        const backTo = route?.params?.backTo;
        if (isSearchTopmostFullScreenRoute()) {
            if (Navigation.getReportRHPActiveRoute()) {
                Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: report.reportID, backTo}), {forceReplace: true});
            } else {
                Navigation.navigate(ROUTES.SEARCH_MONEY_REQUEST_REPORT.getRoute({reportID: report.reportID, backTo}), {forceReplace: true});
            }
        } else {
            Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID, undefined, undefined, backTo), {forceReplace: true});
        }
        openReport(report.reportID);
        reportScrollManager.scrollToBottom();
        return;
    }
    reportScrollManager.scrollToBottom();
    readActionSkipped.current = false;
    readNewestAction(report.reportID);
}, [setIsFloatingMessageCounterVisible, hasNewestReportAction, reportScrollManager, report.reportID, route?.params?.backTo]);

Change 2: Fix goBackFromSearchMoneyRequest in src/components/MoneyRequestReportView/MoneyRequestReportView.tsx (line 67)

Additionally we can update the condition to also check for nested routes within the navigator:

if (rootState.routes.length > 1 || (lastRoute?.state?.routes.length ?? 0) > 1) {
    Navigation.goBack();
    return;
}

This ensures that when navigating back from SEARCH.MONEY_REQUEST_REPORT to SEARCH.ROOT within the SearchFullscreenNavigator, it correctly detects there are routes to go back to (the nested routes) instead of incorrectly forcing navigation to SEARCH_ROOT.

Why this solves the problem:

• forceReplace: true forces the navigation action to be REPLACE instead of PUSH, so the history becomes:

  1. Reports list
  2. Report (after "New messages") ← current page

  Now pressing Back correctly returns to Reports list.

• Preserving backTo maintains the programmatic navigation chain for other navigation scenarios.

• The nested route check fixes related navigation issues in search flows.

[lorretheboy]

Proposal

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

Reports - Clicking 'New messages' button breaks browser back navigation in report view

What is the root cause of that problem?

The issue was in the scrollToBottomAndMarkReportAsRead function which coming from here. When hasNewestReportAction was false (meaning the user wasn't viewing the newest action), the function was calling Navigation.navigate() without any options, which added a new entry to the browser history stack

App/src/pages/home/report/ReportActionsList.tsx

Lines 534 to 542 in 3ee11aa

	if (isSearchTopmostFullScreenRoute()) {
	if (Navigation.getReportRHPActiveRoute()) {
	Navigation.navigate(ROUTES.SEARCH_REPORT.getRoute({reportID: report.reportID}));
	} else {
	Navigation.navigate(ROUTES.SEARCH_MONEY_REQUEST_REPORT.getRoute({reportID: report.reportID}));
	}
	} else {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID));
	}

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

We should modify Navigation.navigate() calls to include {forceReplace: true} option in those three navigation logic to ensure that no new entries are added to the browser history stack

We should not use backTo since it will be deprecated soon

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.

[dmkt9]

Duplicate #71420

[TaduJR]

Oh Yea, You are right @dmkt9
Thank you for pointing out

But I searched for similar issue before submitting this bug.

Lets close this one @izarutskaya
Sorry for the inconvenience