[Due for payment 2026-09-09] Clicking X Replies opens the expense report in normal view instead of Wide RHP

[m-natarajan]

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

Action Performed:

Prerequisite: An expense report with multiple expenses and chat thread

1. Navigate to a Workspace Chat.
2. Open an expense report from the chat to view its details.
3. Locate a thread with replies.
4. Click the X Replies button.
5. Observe how the expense report opens.

Expected Result:

Clicking X Replies should open the expense report in the Wide RHP view, consistent with the standard behavior.
The report should automatically scroll to the corresponding thread/reply when the user lands in the report.

Actual Result:

Clicking X Replies opens the expense report in the normal view instead of the Wide RHP.
The report does not automatically scroll down to the relevant thread/reply.

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

Screenshots/Videos

Recording.3340.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022086822921752071547
• Upwork Job ID: 2086822921752071547
• Last Price Increase: 2026-08-10

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The "X Replies" button routes the child report through old central-pane navigation that predates the super-wide "Expense Report" RHP feature, so it never opts into the wide layout and never carries a scroll anchor. Both symptoms share this one root cause.

Clicking "X Replies" calls navigateToAndOpenChildReport, which navigates to ROUTES.REPORT_WITH_ID.getRoute(report.reportID, undefined, undefined, ...) (or SEARCH_REPORT in Search context). This is wrong in two ways:

• No wide RHP: A money-request/expense child report only opens super-wide when it's routed to EXPENSE_REPORT_RHP (or SEARCH_MONEY_REQUEST_REPORT). The only code that upgrades a report to super-wide is gated on route.name === SEARCH_REPORT and shouldReplaceWithExpenseReportRHP === 'true' — a param this path never sets — so the upgrade can never fire and the report renders in the normal view.
• No scroll-to-reply: Scrolling to a specific action is driven entirely by the reportActionID route param. The 2nd arg to getRoute is reportActionID, and it's passed as undefined, so the URL is just r/<reportID> with no anchor and nothing scrolls.

This is effectively a regression-by-omission: the super-wide RHP routing (PR #75886) and the "open reports/expenses in RHP" link routing (PR #95131) established the new expected behavior, but the thread-reply navigation was never migrated onto that path.

Evidence (file:line)

• Buggy navigation: src/libs/actions/Report/index.ts:2654-2658 — navigateToAndOpenChildReport (the onPress target of ReportActionItemThread.tsx:73-76).
• Super-wide upgrade gate: src/pages/inbox/ReportFetchHandler.tsx:90 and the replace effect at 371-382.
• Wide vs super-wide screen sets: WIDE_RIGHT_MODALS.ts:8-9 (SEARCH_REPORT is only wide; EXPENSE_REPORT / SEARCH_MONEY_REQUEST_REPORT are super-wide).
• The intended routing contract to mirror: Link.ts:370-382 and ParentNavigationSubtitle.tsx:244-252 — both branch on isMoneyRequestReport and route to EXPENSE_REPORT_RHP (or SEARCH_MONEY_REQUEST_REPORT in Search context).
• Scroll anchor is the reportActionID param: read at ReportFetchHandler.tsx:86 → linkedReportActionID at MoneyRequestReportActionsList.tsx:166.

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

Update navigateToAndOpenChildReport so it routes the child report using the same decision the rest of the app already uses, instead of the plain REPORT_WITH_ID / SEARCH_REPORT route:

1. Wide RHP: When the child report isMoneyRequestReport(report), navigate to ROUTES.SEARCH_MONEY_REQUEST_REPORT (Search full-screen context) or ROUTES.EXPENSE_REPORT_RHP (otherwise), mirroring ParentNavigationSubtitle.tsx:244-252. The child report object is already in hand at that point, so no extra fetch is needed. (Alternatively, append shouldReplaceWithExpenseReportRHP='true' to the SEARCH_REPORT route and let ReportFetchHandler upgrade it — but that only covers the Search branch and briefly flashes the narrow RHP first.)
2. Scroll-to-reply: Pass the relevant reportActionID as the 2nd arg so the destination anchors/scrolls to it.

What alternative solutions did you explore? (Optional)

Appending shouldReplaceWithExpenseReportRHP='true' only (rejected as primary — narrow-RHP flash + doesn't cover the central-pane branch). Note the same navigation pattern is duplicated in the explanation-thread helper nearby in Report/index.ts; if that path can also target a money-request child, the same guard should be applied there for consistency.

Confidence & scope notes

Confidence: High — deterministic client-side routing gap, fully explained by code (no production logs needed). The reproduction video in the issue confirms the behavior. If the child of the tapped thread happens to be a chat-type transaction thread (not IOU/Expense type), isMoneyRequestReport would be false and it wouldn't upgrade — worth confirming against the exact repro, but the issue text ("opens the expense report in normal view") indicates the child is a money-request report.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/98142) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[j3ffffff]

Proposal

What is the root cause of that problem?

When you open an expense report from a Workspace Chat, it navigates to ROUTES.EXPENSE_REPORT_RHP (e/:reportID), which renders in SCREENS.RIGHT_MODAL.EXPENSE_REPORT — the "Super Wide RHP" (wide right-hand panel). This is correct.

The bug is in navigateToAndOpenChildReport in src/libs/actions/Report/index.ts (around line 2657). That function is the handler for the "X Replies" button (ReportActionItemThread.tsx). It only has two navigation paths:

1. Search context (isSearchTopmostFullScreenRoute() is true) → navigates to ROUTES.SEARCH_REPORT, opening the thread in the Wide RHP. ✅
2. Everything else → navigates to ROUTES.REPORT_WITH_ID, opening the thread in the normal central-pane/full-screen view. ❌

The inbox expense-report Wide RHP context (SCREENS.RIGHT_MODAL.EXPENSE_REPORT) falls into case 2. So clicking "X Replies" while inside the expense report Wide RHP always opens the child thread in normal view, discarding the Wide RHP context.

The app architecture exposes Navigation.getTopmostSuperWideRHPReportID() precisely to detect when a Super Wide RHP (expense report) is open. This helper is already used elsewhere (e.g. ParentNavigationSubtitle.tsx, dismissToSuperWideRHP) to maintain RHP context, but it was never wired into navigateToAndOpenChildReport.

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

In navigateToAndOpenChildReport (src/libs/actions/Report/index.ts), add a third check between the existing two cases:

• If !isSearchTopmostFullScreenRoute() and Navigation.getTopmostSuperWideRHPReportID() is set (meaning an expense report is currently open in the inbox Super Wide RHP), navigate using ROUTES.EXPENSE_REPORT_RHP.getRoute({reportID: report.reportID}). This pushes the thread onto the Wide RHP stack on top of the expense report, keeping the user in the Wide RHP context and allowing the back button to return to the expense report.

The full logic becomes:

1. Search context → ROUTES.SEARCH_REPORT (existing)
2. Inbox Super Wide RHP context → ROUTES.EXPENSE_REPORT_RHP (new)
3. All other contexts → ROUTES.REPORT_WITH_ID (existing fallback)

No new screens or routes need to be created.

What alternative solutions did you explore? (Optional)

• Navigating to ROUTES.SEARCH_REPORT for the thread even in the inbox context would also put it in the Wide RHP (via RHPReportScreen), but the URL path (search/view/:reportID) would be semantically wrong and could confuse deep-linking or back-navigation.
• Using Navigation.dismissToSuperWideRHP() and scrolling — not applicable since we're navigating to a different report (the child thread), not returning to an existing one.

[melvin-bot]

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

[sobitneupane]

Proposal from @MelvinBot looks good to me.

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @neil-marcellini, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[MelvinBot]

👍 Thanks for the review, sobitneupane — noting the C+ approval on the proposal.

Whenever you're ready to move forward, reply @MelvinBot implement this and I'll open a draft PR that routes navigateToAndOpenChildReport through the wide/super-wide RHP path (EXPENSE_REPORT_RHP / SEARCH_MONEY_REQUEST_REPORT) and passes the reportActionID so the report scrolls to the tapped reply.

[neil-marcellini]

(Neil's AI agent) Not overdue, I was mostly OOO last week. I'll catch up soon