Chat - Profile RHP does not open when returning from Spend via device back button

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.91-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #99295
Email or phone of affected tester (no customers): jsjiodnjosdjosjoijo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Chat Report View

Action Performed:

1. Go to staging.new.expensify.com
2. Go to any chat.
3. Send a message.
4. Click on your user avatar.
5. Click Edit profile.
6. Click browser back button (or device back button).
   → Profile RHP opens.
7. Click View user history.
8. Click browser back button (or device back button).

Expected Result:

Profile RHP will open.

Actual Result:

Profile RHP does not open when returning from Spend via device back button.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7265777_1790026615944.11.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7265777

[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/47a23d4aee2635effa995df2d769a059abc505a71ef3063922d52152107b5f0f

[melvin-bot]

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

[melvin-bot]

@Julesssss @marufsharifi you have been assigned to this deploy blocker because you reviewed the offending PR: #99295

[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.

[melvin-bot]

@hungvu193 you have been assigned to this deploy blocker because you authored the offending PR: #99295

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #99295 - "Add search this user/agent to ProfilePage" by @hungvu193 (High confidence)
Related Issues: Agents - Verify account page opens after swiping back three times from View agent history (Expensify/App#99073) — the previous deploy blocker on this same feature, whose fix is what introduced this one

Recommendation: REVERT

The one-line "obvious fix" (switching back to Navigation.navigate) would directly reintroduce Expensify/App#99073, so there is no safe roll-forward available under deploy-blocker time pressure. Since this feature is not in production and has now caused two blockers on the same line, revert #99295 and re-land once the navigation semantics are settled.

Assigned: @hungvu193 (PR author), @Julesssss and @marufsharifi (approving reviewers) from #99295 — already assigned by melvin-bot
Labels: No changes. DeployBlockerCash is kept (an App PR caused this). DeployBlocker was not present, so nothing was removed.

📋 Detailed Analysis

Evidence

• #99295 is the PR that adds the "View user history" / "View agent history" menu item to the profile RHP — the exact entry point in the repro steps. It merged 2026-09-21 and is in this release's checklist.
• Reproducible on staging only, not on production, which matches: this feature does not exist in production.
• It is a revert-of-a-revert. The feature first shipped as #98091, was reverted by #99104 because of deploy blocker Expensify/App#99073 (back navigation after "View agent history" landed on the wrong screen), and was then re-landed as #99295.
• The fix folded into the re-land is precisely the cause of this blocker. The attempted fix PR #99077 changed this single call from Navigation.navigate(...) to Navigation.revealRouteBeforeDismissingModal(...), and that change is what shipped in #99295.
• I checked every other PR in Deploy Checklist: New Expensify 2026-09-21 (Expensify/App#101773). Comparing production...staging, none of the navigation history/reveal files changed in this release — Navigation.ts, addRootHistoryRouterExtension.ts, addRootHistoryRouterExtensionUtils.ts and GetStateForActionHandlers.ts are all identical to production. The reveal machinery is pre-existing and unchanged; the only new thing in this release is the new call site added by #99295. No other candidate PR touches this path.

Verification

Affected file: src/pages/ProfilePage.tsx

• Offending line: ProfilePage.tsx#L342 — Navigation.revealRouteBeforeDismissingModal(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query})), inside the onPress of the "View user history" menu item added by #99295.
• Confirmed #99295 modifies this file: its file list includes src/pages/ProfilePage.tsx (+17/-1), and the diff hunk at @@ -327,6 +329,20 @@ is exactly the menu item in the repro.
• Supporting signal — the sibling call site added by the same PR does not have the bug: EditAgentPage.tsx#L93 still uses plain Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute(...)). Only the RHP call site was switched to the reveal path, which is why only the profile RHP flow regressed.

Root Cause

revealRouteBeforeDismissingModal is not plain navigation — it deliberately suppresses the browser/native history push so the dismissed RHP is not reachable via Back.

1. Navigation.ts#L1107-L1127 dispatches REPLACE_FULLSCREEN_UNDER_RHP to slot the Search tab underneath the open RHP, then DISMISS_MODAL on the next frame.
2. addRootHistoryRouterExtension.ts#L92-L101 states the intent directly: "DISMISS that completes the reveal: pad new history to pre-DISMISS length so useLinking sees historyDelta=0 and just history.replaces the current entry."
3. addRootHistoryRouterExtensionUtils.ts#L155-L165 implements it by prepending CUSTOM_HISTORY_ENTRY_REVEAL_PADDING entries so the history length is unchanged across the dismiss.

Net effect in the repro: the history entry for the profile RHP (/a/<accountID>) is replaced by /search?q=... rather than being pushed on top of it. Pressing Back therefore pops to whatever preceded the profile RHP — the chat report — and the profile RHP is gone from history entirely. That is the reported symptom.

This is correct behaviour for the flow the API was built for (submit an expense, then reveal Search — you must not be able to go Back into a half-finished creation form). It is wrong for a "View user history" link, because the profile RHP is a persistent, re-openable view the user legitimately expects Back to return to.

Note the trade-off that makes the one-liner unsafe: Navigation.navigate here keeps the RHP in history (fixing this issue) but leaves the stale RHP entries that caused Expensify/App#99073 ("swipe back three times" not landing on the Agents page). A correct fix needs the RHP dismissed and a single history entry for the profile RHP preserved — neither of the two options tried so far does both. That is more than a deploy-blocker-window change, hence the revert.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards amendment so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: amend the existing PERF-18 (Use usePreMountDestination for RHP-to-fullscreen pre-mounting) rather than adding a new rule — it already lists revealRouteBeforeDismissingModal as a search pattern, but its "When NOT to use" section only covers mounting/perf concerns and says nothing about the history side effect.
• Condition: flag revealRouteBeforeDismissingModal (and usePreMountDestination().reveal) when the RHP being dismissed is a persistent, re-openable screen (a profile, a details page, a settings page) rather than a terminal submit/create flow. The reveal path replaces the RHP's history entry, so Back can never return to it. For a plain "go look at X" menu item, use Navigation.navigate instead.
• Why: the reveal path pads state.history to keep historyDelta === 0 so useLinking calls history.replace instead of pushing, which silently deletes the RHP's history entry and breaks browser/device Back. Harm demonstrated by this issue.
• Search pattern: rg 'revealRouteBeforeDismissingModal\(' src/ — for each hit, check whether the enclosing RHP is a terminal creation/submission flow (OK) or a re-openable view reached from a menu item (flag).
• Offending code (❌): ProfilePage.tsx#L342
• Fix (✅): the sibling call site that got it right — EditAgentPage.tsx#L93

The full amendment, with the ❌/✅ code inline in Expensify/App's coding-standards format, would go in .claude/skills/app-coding-standards/rules/perf-18-use-pre-mount-destination.md. If it's worth adding, a maintainer can open it there as a draft PR.