WS chat - Clicking an expense card opens both the parent report and the specific expense

[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.45-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: #92546
Email or phone of affected tester (no customers): applausetester+bm89880@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Web
App Component: Chat Report View

Action Performed:

Preconditions:
Open a workspace chat that contains an expense report with more than one expense

1. Go to staging.new.expensify.com
2. Open the workspace chat from the preconditions.
3. Click the first expense card.

Expected Result:

Only the specific expense should open,

Actual Result:

Both the parent report and the specific expense open.
Step 3 of the pr tc fails

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7219116

[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/240bf17995b971be2bf0fcfdad4f8c545cd79884a38d1f4444a019a033878168

[melvin-bot]

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

[melvin-bot]

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

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

[MelvinBot]

Issue Analysis

Root Cause: This is the intended cascade behavior introduced by PR #92546 — not an accidental double-open. On wide layouts (Windows Chrome), clicking an expense card deliberately (1) opens the parent report in the wide RHP and then, ~180ms later, (2) opens the specific expense on top of it, so that pressing back returns you to the report rather than straight to the chat. See MoneyRequestReportPreview/index.tsx:248-267. Because both screens stay mounted, the tester sees "both the parent report and the specific expense open."

The problem is that this contradicts the PR's own test step 3 ("opens that specific expense … not the parent report"). So the acceptance criteria and the implemented UX disagree.

Two sub-cases — the QA screenshot decides which:

• (a) The parent report is fully visible/lit beside the expense → the SecondaryOverlay that is supposed to dim the exposed report strip (WideRHPOverlayWrapper — the isWideRHPDisplayedOnSuperWideRHP case) is not rendering on web. That's a genuine bug to fix.
• (b) The parent report is dimmed behind the expense → the feature is working as designed, and the failing test step / expectation needs to be reconciled with the intended cascade.

Recommended next step (deploy blocker): Confirm the intended UX with the PR author (wildan-m) / design:

• If the cascade (report behind, expense on top) is the desired behavior → update test step 3 to reflect that the parent report is expected behind the expense, and verify the dimming overlay renders on Windows Chrome.
• If only the expense should open on wide layouts → drop the EXPENSE_REPORT_RHP navigation at index.tsx:253-254 and open only the SEARCH_REPORT expense.

Given the ambiguity is about intended UX rather than a clear code defect, this likely warrants a quick design confirmation before reverting or patching.

Investigation details

Mechanism (wide layout), from navigateToExpense):

1. markReportRHPWidth(iouReportID, 'super-wide') + Navigation.navigate(EXPENSE_REPORT_RHP) — parent report opens in a super-wide RHP.
2. After PRESSED_EXPENSE_CASCADE_DELAY (180ms, index.tsx:53): markReportRHPWidth(childReportID, 'wide') + Navigation.navigate(SEARCH_REPORT) — the pressed expense opens on top.

Both RHP screens stay mounted (the WideRHP provider explicitly supports "two or more RHPs on the stack"). Because wide width is narrower than super-wide, the report is geometrically exposed on the left; a dedicated SecondaryOverlay in WideRHPOverlayWrapper/index.tsx is meant to mask that strip so the report reads as dimmed behind the expense. If that overlay fails to render/animate on Windows Chrome, the report stays fully visible → the reported symptom.

Why this looks like a regression: The linked issue #91042 asked for clicking a card to open the clicked expense (previously every card opened the parent report). The PR solved that but chose a report→expense cascade on wide layouts, which reintroduces the parent report into the view — visible to the tester and flagged against the PR's own "not the parent report" wording.

Alternative explanations considered: A true double-navigation bug (e.g. both openReportFromPreview and navigateToExpense firing) — ruled out: the single-expense guard routes lone-expense reports to openReportFromPreview, but multi-expense reports go only through navigateToExpense, which itself performs the two intentional navigations. The "both open" is by construction, not a stray extra call.

---

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (App PR involved) — but see recommendation, this is very likely working-as-designed
Causing PR: #92546 - "Navigate to the clicked expense in a multi-expense report preview" by @wildan-m (High confidence it produced the observed behavior)
Related Issues: #91042 (the feature request this PR implements)

Recommendation: ROLL FORWARD (targeted fix-forward if a real defect is confirmed) — do NOT revert

The "both open" behavior is the intended report→expense cascade on wide layouts, built on the same pre-existing WideRHP super-wide + wide stacking that already ships in production for Search. The only genuine defect would be the dimming SecondaryOverlay failing to render on Windows Chrome; if that is confirmed from the QA video, fix it in the overlay path rather than reverting a large, well-reviewed feature PR.

Assigned: @wildan-m (PR author), @jayeshmangwani (approving reviewer), @MonilBhavsar (approving reviewer, already assigned) from PR #92546
Labels: No change — keeping DeployBlockerCash. (App deploy blocker; an App PR is involved; do not remove.)

📋 Detailed Analysis

1. Causing PR — confirmed

• PR Navigate to the clicked expense in a multi-expense report preview #92546 merged 2026-07-27 07:03 UTC and is item Add Android app icon #74 (unchecked) in the current StagingDeployCash (Deploy Checklist: New Expensify 2026-07-27 #97134), so it is part of 9.4.45 on staging. Version and staging-only reproduction (N/A in prod — new feature) both align.
• It modifies src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx (+215/-21), which is exactly the multi-expense preview card press path in the report. No other PR in the checklist touches this component. Confidence the PR produced the symptom: High.

2. Is "both open" a bug or the intended cascade?

It is the intended cascade, by construction. On wide layouts navigateToExpense deliberately opens two RHP screens:

navigateToExpense, index.tsx#L248-L269:

1. markReportRHPWidth(iouReportID, 'super-wide') + Navigation.navigate(EXPENSE_REPORT_RHP) → parent report opens in a super-wide RHP.
2. After PRESSED_EXPENSE_CASCADE_DELAY (180ms, index.tsx#L53): markReportRHPWidth(childReportID, 'wide') + Navigation.navigate(SEARCH_REPORT) → the pressed expense opens wide, on top.

Both screens stay mounted on purpose so Back → report → chat. This is not a stray double-navigation: the single-expense guard sends lone-expense reports through openReportFromPreview (index.tsx#L287-L292); multi-expense reports go only through navigateToExpense, whose two navigations are the whole design.

This stack shape is production-proven. The route→width mapping in WIDE_RIGHT_MODALS.ts#L8-L9 puts EXPENSE_REPORT in SUPER_WIDE_RIGHT_MODALS and SEARCH_REPORT in WIDE_RIGHT_MODALS, so the resulting stack is exactly "Wide RHP displayed on Super-Wide RHP". That is identical to the Search flow, where a multi-expense report is marked super-wide (Search/index.tsx#L600) and a clicked transaction opens wide on top (Search/index.tsx#L647-L657). That flow is in production today with the report dimmed behind the expense.

PR #92546 does not touch any WideRHP / overlay file — it reuses this existing infrastructure. So the dimming that makes the report read as "behind" rather than "also open" is handled by code that already works on web wide layouts.

3. Where the dimming comes from (and the only place a real bug could be)

The exposed strip of the super-wide report is masked by SecondaryOverlay's isWideRHPDisplayedOnSuperWideRHP branch, WideRHPOverlayWrapper/index.tsx#L53-L60, gated by shouldRenderSecondaryOverlayForWideRHP = isRHPFocused && isSuperWideRHPBelow && (isWideRHPFocused || isWideRHPBelow) (WideRHPContextProvider/index.tsx#L189). For the report→expense stack those conditions hold, so the overlay is expected to render on web wide layout.

The QA artifact is a video (video/mp4); I could not frame-analyze it automatically. Two sub-cases:

• (a) Report is dimmed behind the expense → working exactly as designed. The failing "step 3" is a spec/wording mismatch: the PR's own step 3 says "not the parent report", but the author deliberately shipped a cascade (report behind, expense on top) for wide layouts. → DEMOTE / reconcile the test step, do not block.
• (b) Report is fully lit / co-equal (overlay absent on Windows Chrome) → a real but narrow defect in the overlay rendering for this stack. → targeted fix-forward in the WideRHP overlay path (shouldRenderSecondaryOverlayForWideRHP gating in WideRHPContextProvider/index.tsx:189 or the isWideRHPDisplayedOnSuperWideRHP branch in WideRHPOverlayWrapper/index.tsx:53-60), NOT a revert.

In both sub-cases the fix is small and localized; a revert would remove the whole #91042 feature and reintroduce the original bug (every card opening the parent report), which is worse. Hence ROLL FORWARD.

Verification checklist

• PR modifies the affected component (MoneyRequestReportPreview/index.tsx) — yes, the press path itself.
• Changes relate to the symptom — the two intentional navigations produce "both open".
• Merge date aligns — merged 07-27, on 9.4.45 staging, reported same day; N/A in prod (new feature).
• Overlay/WideRHP files are NOT changed by the PR — the dimming is existing, production-proven infrastructure (same stack as Search multi-expense expand).

[MonilBhavsar]

Feature and not a bug