[Due for payment 2026-03-19] Attachment - Long press on the attachment doesn't open the action menu

[jponikarchuk]

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.3.36-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-8439/folder/13176710/41236957/1244462782?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 13 iOS 26.3
App Component: Chat Report View

Action Performed:

1. Open the app
2. Open any chat with attachment
3. Long press on any attachment

Expected Result:

Long press on the attachment should open the action menu

Actual Result:

Long press on the attachment doesn't open the action menu

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @srikarparsi (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #83575 - "Improve Sentry INP interaction grouping via data-sentry-label early-return" by @adhorodyski (Medium confidence)
Related Issues: None found

Recommendation: NEEDS INVESTIGATION

The causing PR is not definitive. PR #83575 modified the Pressable component implementation and Sentry patches, which could potentially interfere with long press gesture recognition on mobile, but the connection is not conclusive. The PR author and reviewer should investigate whether the Sentry patch changes could affect touch event handling on iOS/Android.

Labels: Keeping DeployBlockerCash (this is a mobile app issue and not reproducible on production)

📋 Detailed Analysis

Evidence

• The issue affects long press on attachments in chat (iOS & Android apps)
• Long press is handled by onLongPress handlers in Pressable components
• PR Improve Sentry INP interaction grouping via data-sentry-label early-return #83575 was merged on 2026-03-10 and modified:
  • src/components/Pressable/GenericPressable/implementation/index.tsx
  • Sentry core patches that walk the DOM and check for aria-disabled attributes
• This PR is in the staging deploy (9.3.36-0) but not in production

Verification

I verified that:

• ImageRenderer.tsx (which renders chat attachments) DOES have an onLongPress handler that calls showContextMenuForReport (lines 121-128)
• The ShowContextMenuContext code that handles context menus has NOT changed since Feb 1
• The DeviceCapabilities check for canUseTouchScreen() has NOT changed
• No other obvious changes to long press handling in the codebase since Feb 15

Root Cause Hypothesis

PR #83575 added logic to the Sentry patch that:

1. Searches for data-tag="pressable" elements when building interaction selectors
2. Checks for aria-disabled="true" and skips those elements

While this patch is intended only for Sentry tracking, there may be an unintended side effect where:

• The patch code runs during event handling and interferes with touch gestures on mobile
• OR there is a timing/race condition introduced that prevents long press from being recognized
• OR the changes to how Pressable elements are tracked causes some state management issue

Alternative Possibilities

1. The issue might be unrelated to code changes and caused by a backend/infrastructure change
2. There might be a PR I missed that affected attachment rendering or event handling
3. The issue might be specific to certain devices/OS versions not covered in PR testing

[OSBotify]

@adhorodyski Could you please review this issue? Your PR #83575 was merged on March 10 and is the most likely cause based on timing. The Sentry patch modifications you made could potentially affect touch event handling on mobile devices. Can you investigate whether the DOM walking logic or the aria-disabled checks could interfere with long press gesture recognition on iOS/Android?

@jponikarchuk Can you confirm whether this issue affects ALL attachments or only specific types? Does it happen on all chats or only certain ones? This information will help narrow down the cause.

[MelvinBot]

Proposal

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

Long-pressing on an attachment (image, video, or file) in a chat does not open the action/context menu on iOS and Android native apps. This is a regression in staging (v9.3.36-0) that does not occur in production.

What is the root cause of that problem?

PR #81807 introduced a new variable shouldDisplayContextMenuValue in PureReportActionItem.tsx to hide the context menu for Concierge greeting messages. Most usages were updated correctly, but the context provider value object at line 833 was changed from:

shouldDisplayContextMenu,

to:

shouldDisplayContextMenuValue,

In JavaScript shorthand property notation, { shouldDisplayContextMenuValue } creates a property named shouldDisplayContextMenuValue, not shouldDisplayContextMenu. The context type expects shouldDisplayContextMenu (defined at src/components/ShowContextMenuContext/types.ts:12), but the provider now supplies a differently-named property.

All child components that consume this context — ImageRenderer, VideoRenderer, PreRenderer, MentionUserRenderer, VideoPlayerThumbnail, and BaseAnchorForAttachmentsOnly — destructure shouldDisplayContextMenu and get undefined. Their onLongPress handlers check if (!shouldDisplayContextMenu) { return; }, and since !undefined === true, the handler returns early and the context menu never appears.

TypeScript didn't catch this because shouldDisplayContextMenu is optional (?) in the type definition.

This only affects native platforms because on web, the context menu is triggered by right-click through the outer PressableWithSecondaryInteraction which uses shouldDisplayContextMenuValue directly (correctly). On native, long-pressing on an attachment triggers the inner pressable's onLongPress which reads from the broken context.

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

In src/pages/inbox/report/PureReportActionItem.tsx, line 833, change the shorthand property to an explicit mapping:

shouldDisplayContextMenu: shouldDisplayContextMenuValue,

This maps the local variable to the expected context property name, restoring correct behavior for all consumers.

What alternative solutions did you explore? (Optional)

An alternative would be to rename the context type field and update all consumers to use shouldDisplayContextMenuValue, but that would be a larger and unnecessary change. The minimal fix of explicitly mapping the property name in the provider is the cleanest approach.

---

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.