[Due for payment 2026-06-17] [Due for payment 2026-06-17] Distance - Only the map appears when hovered after closing RHP

[applause-bot]

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.4.1-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: #92525
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a distance expense.
4. Open the report.
5. Click Amount.
6. Hover over distance receipt, then click outside to close the RHP.

Expected Result:

Full distance e-receipt will appear when hovered.

Actual Result:

Only the map appears when hovered after closing RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7175616_1780981781477.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7175616

[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/57f6820d2def34273571866e6e4a23dd328183e3501f0607f2bb1c5493d55dbc

[melvin-bot]

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

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

Proposal

What is the root cause of that problem?

This is a regression from the brand‑new hover overlay added in #92525.

The hover overlay HoveredDistanceEReceipt doesn't show the full e‑receipt at a fixed size — it renders the full DistanceEReceipt card and then scales it down to fit the receipt box using values it learns from onLayout:

scale = min(boxWidth / CARD_WIDTH, boxHeight / cardHeight)   // 0 until all three are measured

(scale calc, onLayout handlers)

cardHeight is the measured height of the DistanceEReceipt card, which has no deterministic height — it's a ScrollView whose height depends on content (map image, waypoint count) and on the box that bounds it (DistanceEReceipt ScrollView).

The overlay is freshly mounted on every hover (gated on hovered at MoneyRequestReceiptView L649), so it always starts from width/height = 0 and depends entirely on onLayout timing. On a first hover (report freshly loaded, layout settled) the measurements are correct and the card scales to fit. After opening the Amount RHP and clicking outside to close it, the central‑pane layout changes (RHP collapses, the receipt box re‑sizes) and the card is measured before its content settles, so cardHeight comes back too small. That inflates boxHeight / cardHeight, the card is scaled larger than the box, and the overlay's overflowHidden clips everything except the top of the card — which is the map. Net visible result: only the map appears on hover.

Why "only the map" rather than "nothing" or "wrong size"

• When no measurement has arrived, the card is opacity0 (L41) → you'd see only the green fill, no map. That's not what's reported.
• "Only the map" means a non‑zero scale was computed but the card overflows the box top‑down. The map is the first/top element of DistanceEReceipt; amount + waypoints + footer are clipped below the fold by overflowHidden.
• The trigger (isLoading reset / re‑layout after the RHP closes) is what causes the stale/too‑small cardHeight. The underlying fragility is that the overlay derives a transform scale from async, content‑dependent onLayout values that aren't guaranteed to stay in sync across a re‑layout.

This is consistent with the sibling deploy blocker #93001 (also from #92525), which is the same hover‑overlay measurement path misbehaving for a different receipt type.

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

Make the overlay's scale robust to re‑layout instead of trusting a one‑shot, content‑dependent measurement:

1. Re‑measure on every layout change and recompute scale whenever box or card size changes (rather than letting the first measured cardHeight "stick"), so a post‑RHP re‑layout corrects the scale instead of clipping. In HoveredDistanceEReceipt, this means treating onCardLayout/onOverlayLayout as live and recomputing — and guarding against a transient cardHeight of 0/too‑small (keep the card opacity0 until a stable, non‑trivial cardHeight is measured).
2. Give the measured card a deterministic intrinsic height so cardHeight doesn't depend on ScrollView collapse — measure the inner eReceiptPanel (which has a real content height) rather than the flex1 + ScrollView wrapper, or render the measured copy without the ScrollView so its layout height equals its content height.

Either of these removes the dependency on render timing that the RHP open/close cycle currently breaks.

What alternative solutions did you explore? (Optional)

If a quick, low‑risk deploy‑blocker unblock is preferred over a proper fix, the overlay feature from #92525 could be reverted (or feature‑gated off) and re‑landed with deterministic sizing, since this and #93001 are both regressions introduced by it.

⚠️ Confidence: Medium. Root cause is traced from the new code and matches the "only the map" symptom and the RHP‑cycle trigger, but I have not reproduced it in a running browser to capture the exact measured cardHeight/scale values. The PR author can confirm quickly by logging boxWidth/boxHeight/cardHeight/scale in HoveredDistanceEReceipt across the repro steps.

Related: #93001 — same PR (#92525), same hover‑overlay path, likely a shared fix.

---

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