Fix 'Not Found' page flash after deleting expense#83613

Draft

MelvinBot wants to merge 1 commit intomainfrom

claude-fixNotFoundFlashOnDeleteExpense

Contributor

MelvinBot commented Feb 26, 2026

Explanation of Change

The DeleteTransactionNavigateBackHandler component (used by ReportScreen) had an inverted focus condition when clearing the deleteTransactionNavigateBackUrl guard. It was clearing the guard while the screen was still focused (!isFocused), which allowed shouldShowNotFoundPage to briefly evaluate to true before navigation completed — causing a "Not Found" page flash.

This fix changes the condition to isFocused (matching the correct pattern already established in SearchMoneyRequestReportPage.tsx:111), so the guard URL is only cleared after the user has navigated away from the screen.

Fixed Issues

$ #83521
PROPOSAL: #83521 (comment)

Tests

Go to a chat and create a single expense
Open the expense
Click the report details (header)
Delete the expense from the details page
Verify the navigation back is smooth with no "Not Found" page flash

Regression test (forward button behavior from original PR #79530):

Go to a workspace chat
Create two expenses with the same amount (e.g., $10.00 each)
Open the expense report
Click "Review duplicates" in the header
Click on the first expense preview to open it
Click More → Delete → confirm deletion
Click the browser forward button
Verify "Not Found" page is shown (not the deleted expense or infinite loading)

Verify that no errors appear in the JS console

Offline tests

Repeat the deletion test steps 1-4 above while offline
Verify the navigation back is smooth with no "Not Found" page flash
Reconnect to the network
Verify no errors appear

QA Steps

Same as Tests

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Not applicable - logic-only change, no UI modification.

Android: mWeb Chrome

Not applicable - logic-only change, no UI modification.

iOS: Native

Not applicable - logic-only change, no UI modification.

iOS: mWeb Safari

Not applicable - logic-only change, no UI modification.

MacOS: Chrome / Safari

Not applicable - logic-only change, no UI modification.


          Fix 'Not Found' page flash after deleting expense

fcc94f3

The deleteTransactionNavigateBackUrl clearing effect in
DeleteTransactionNavigateBackHandler had an inverted focus condition
compared to SearchMoneyRequestReportPage. It cleared the guard URL
while the screen was still focused, allowing the Not Found page to
briefly flash before navigation completed. Changed the condition to
only clear after navigating away, matching the established pattern.

Co-authored-by: Krishna <Krishna2323@users.noreply.github.com>

MelvinBot assigned Krishna2323

MelvinBot requested a review from a team

February 26, 2026 19:18

Contributor Author

MelvinBot commented Feb 26, 2026

I created this PR from an upstream branch since I don't have push access to your fork.

To take ownership of this branch and be able to push updates, run:

git remote add upstream https://github.com/Expensify/App.git
git fetch upstream claude-fixNotFoundFlashOnDeleteExpense
git checkout -b claude-fixNotFoundFlashOnDeleteExpense upstream/claude-fixNotFoundFlashOnDeleteExpense
git push -u origin claude-fixNotFoundFlashOnDeleteExpense

Then you can close this PR and open a new one from your fork.

MelvinBot mentioned this pull request

[$250] "Not Found" page flash after deleting expense #83521

Open

7 tasks

Contributor

Krishna2323 commented Feb 26, 2026

@MelvinBot The issue is not fixed. While keeping the updates seems reasonable to me, the root cause appears to be a timing issue.

This only occurs on slower devices, where it takes some time for the RHP/Details page to close after the report is deleted. During that transition, the “Not Found” page becomes briefly visible while the RHP is closing.

Contributor Author

MelvinBot commented Feb 26, 2026

Thanks for the feedback Krishna2323 — you're right that this is a timing issue. After investigating further, the fix in this PR addresses one layer of the problem (when the deleteTransactionNavigateBackUrl guard is cleared on the underlying ReportScreen), but the flash on slower devices comes from a second layer: the RHP page itself.

Root Cause

The withReportOrNotFound HOC wrapping ReportDetailsPage has a guard at withReportOrNotFound.tsx:97-101:

if (shouldShowNotFoundPage && contentShown.current && !isFocused) {
    return null; // prevents NotFound during close animation
}

This guard only returns null when !isFocused. On slow devices, there's a race condition:

Delete is confirmed → navigation dispatch + deleteTransaction() run in the same requestAnimationFrame callback
RHP starts its 300ms close animation
Onyx updates propagate: report data empties → shouldShowNotFoundPage = true
But isFocused is still true for the RHP page (blur event hasn't propagated yet)
The guard doesn't fire → HOC renders <NotFoundPage /> inside the still-visible, animating-out RHP panel → flash
Then isFocused flips to false → guard returns null → but flash already happened

Precedent in the Codebase

This exact pattern is already handled for transaction duplicate reviews in RightModalNavigator.tsx:130-135:

// Delay clearing review duplicate data till the RHP is completely closed
// to avoid not found showing briefly in confirmation page when RHP is closing
InteractionManager.runAfterInteractions(() => {
    abandonReviewDuplicateTransactions();
});

Suggested Fix

The deleteTransaction() call in ReportDetailsPage.tsx:1013-1016 should be deferred until after the RHP close animation completes, similar to the duplicate review pattern:

Navigation.setNavigationActionToMicrotaskQueue(() => {
    navigateToTargetUrl();
    // Delay deletion until RHP close animation finishes
    InteractionManager.runAfterInteractions(() => {
        deleteTransaction();
    });
});

This ensures the report data stays intact while the RHP is still visible and animating closed. The condition fix in this PR (clearing the guard when !isFocused) is still correct and useful for ReportScreen, but the RHP-level flash needs this additional timing fix.

Want me to update this PR with the InteractionManager approach?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet