[Due for payment 2026-03-30] Chat Report View - Enlarge and plus buttons on receipt image persist without hover

[mitarachim]

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: v9.3.32-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: #83994
Email or phone of affected tester (no customers): dfghnhgfd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Chat Report View

Action Performed:

Preconditions:

• Logged in to any account
• Has expense with an attached receipt image

Steps:

1. Navigate to the workspace chat that has expense with an attached receipt image
2. Open the expense details
3. Observe the receipt image

Expected Result:

Enlarge and plus button should only appear if user hover on the receipt image and it should disappear if user move the mouse away from the receipt image

Actual Result:

Enlarge and plus buttons on receipt image persist without hover

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7095356_1772783628779.hoverr.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @RachCHopkins (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #83994 - "feat: allow multiple receipts to be attached to a single expense" by @TaduJR (High confidence)
Related Issues: #81435

Recommendation: REVERT

PR #83994 introduced hover-based buttons (enlarge and add receipt) on receipt images. However, the hover logic fails on Windows devices with touchscreens because the canUseTouchScreen() detection treats these hybrid devices as pure touch devices, disabling hover functionality even when users interact with a mouse.

Labels: DeployBlockerCash label should be kept (this blocks the App deploy). DeployBlocker label should be removed (this is not a backend bug).

Detailed Analysis

Evidence

• The issue description explicitly links to PR feat: allow multiple receipts to be attached to a single expense #83994 in the BrowserStack test URL
• Bug appears on Windows 11 / Chrome - a platform that often has touchscreen capabilities
• Issue is staging-only and reproducible, matching PR feat: allow multiple receipts to be attached to a single expense #83994 merge timeline (merged 2026-03-05)
• The expected behavior described in the issue matches exactly what PR feat: allow multiple receipts to be attached to a single expense #83994 was supposed to implement: "Enlarge and plus button should only appear if user hover on the receipt image"

Verification

PR #83994 modified:

• src/components/ReportActionItem/MoneyRequestReceiptView.tsx - Added the hover buttons and hover logic
• src/styles/index.ts - Added styling for the button container
• src/CONST/index.ts - Added button constants

These are the exact files and components affected by the reported bug.

Root Cause

The hover implementation uses this logic in MoneyRequestReceiptView.tsx:

const isTouchScreen = canUseTouchScreen();
// ...
<View style={[styles.receiptActionButtonsContainer, styles.pointerEventsBoxNone, !hovered && !isTouchScreen && styles.opacity0]}>

The problem:

1. canUseTouchScreen() checks navigator.maxTouchPoints > 0 on web
2. On Windows 11 devices with touchscreens, this returns true even when the user is using a mouse
3. When isTouchScreen is true, the condition !hovered && !isTouchScreen is always false
4. Therefore, styles.opacity0 is never applied, and the buttons remain visible at all times
5. The useHover hook also disables hover tracking when canUseTouchScreen() returns true, so hovered never becomes true from mouse interactions

This is a fundamental issue with treating hybrid devices (laptops with touchscreens) as pure touch devices in the hover detection logic.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After PR #83994 merged, the enlarge and plus buttons overlaid on receipt images in the expense detail view are always visible on web (Chrome on Windows), instead of only appearing when the user hovers over the receipt image.

What is the root cause of that problem?

The button visibility in MoneyRequestReceiptView relies on canUseTouchScreen() to distinguish mobile (always-show) from desktop (show-on-hover). The relevant line is:

<View style={[styles.receiptActionButtonsContainer, styles.pointerEventsBoxNone, !hovered && !isTouchScreen && styles.opacity0]}>

canUseTouchScreen() (at src/libs/DeviceCapabilities/canUseTouchScreen/index.ts) checks navigator.maxTouchPoints > 0. On Windows laptops with touchscreen capability (or certain Chrome configurations), maxTouchPoints is greater than 0 even when the user is using a mouse. This causes isTouchScreen to be true on desktop web, which means !isTouchScreen is false, so styles.opacity0 is never applied — the buttons remain permanently visible.

Additionally, the useHover hook (src/hooks/useHover.ts) gates its onMouseEnter handler behind !canUseTouchScreen, so even if the visibility condition were different, hovered would never become true on these affected machines because mouse events are silently ignored.

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

Replace the canUseTouchScreen() check with a more reliable method to determine whether hover should be supported. Two options:

Option A (Recommended): Use the Hoverable component (the established pattern in the codebase, used by BaseVideoPlayer, TaskView, etc.) instead of the useHover hook. Hoverable delegates to ActiveHoverable on web which manages mouse enter/leave robustly, and on native (index.native.tsx) it always passes hovered=false. Use conditional rendering (like BaseVideoPlayer does) instead of opacity toggling:

Hoverable wrapping the receipt area →
  isHovered provided via render-prop →
  conditionally render buttons when (isHovered || isMobile)

This eliminates both the canUseTouchScreen() dependency and the need for pointerEventsBoxNone on the buttons container.

Option B: Replace canUseTouchScreen() with a platform/layout check. For example, use shouldUseNarrowLayout from useResponsiveLayout() (already imported in the component) to determine mobile vs desktop context, since it uses screen dimensions rather than touch capability detection.

In both options, the change is localized to src/components/ReportActionItem/MoneyRequestReceiptView.tsx.

What alternative solutions did you explore? (Optional)

• Using CSS @media (hover: hover) media query to detect hover capability — this is the web-standards approach but would require platform-specific style handling that doesn't align with the existing React Native pattern.
• Removing the canUseTouchScreen guard from the useHover hook itself — this would fix the immediate issue but could break other consumers of the hook that rely on the current behavior.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.