[Due for payment 2026-05-22] [$250] mWeb - Attachments - Navigation buttons do not appear or disappear when tapping the PDF document

[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: v9.3.50-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176710/test-cases/41236944
Email or phone of affected tester (no customers): agexptest+pr270326g@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Samsung S23FE/ Android 16
App Component: Chat Report View

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Go to any 1:1 chat
3. Send several attachments, including a PDF document
4. Tap on the PDF preview
5. Once a larger preview of the PDF is displayed, tap it repeatedly

Expected Result:

The navigation buttons show and hide respectively.

Actual Result:

The navigation buttons do not appear or disappear when tapping the PDF document.

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

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037798046713936211
• Upwork Job ID: 2037798046713936211
• Last Price Increase: 2026-05-09

[samranahm]

Proposal

What is the root cause of that problem?

PDF taps are currently toggling the same handler twice on mWeb touch devices, so the arrows flip on and then immediately off.

In BaseAttachmentViewPdf, a single PDF tap could call the same arrow-toggle handler twice on mWeb touch flow

• First via onPressProp(event) (passed from carousel as handleTap)
• Again via actions.onTap?.() from context

Because both references point to the same function, visibility toggled twice (hidden -> shown -> hidden), so navigation buttons appeared to never change.

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

We should ppdate BaseAttachmentViewPdf.tsx to avoid duplicate invocation:

Keep calling onPressProp(event) when provided
Call actions.onTap?.() only if onPressProp !== actions.onTap

    if (state !== null && actions && isScrollEnabled?.get() && onPressProp !== actions.onTap) {
        actions.onTap?.();
    }
},

here

App/src/components/Attachments/AttachmentView/AttachmentViewPdf/BaseAttachmentViewPdf.tsx

Lines 56 to 65 in ed5bbfd

	const onPress = useCallback(
	(event?: GestureResponderEvent | KeyboardEvent) => {
	if (onPressProp !== undefined) {
	onPressProp(event);
	}
	if (state !== null && actions && isScrollEnabled?.get()) {
	actions.onTap?.();
	}
	},

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[MelvinBot]

Proposal

What is the root cause of that problem?

On Android mWeb, tapping a PDF in the attachment carousel doesn't toggle navigation arrows because touch events are intercepted by inner PDF layers before reaching the tap handler.

The toggle mechanism works through a PressableWithoutFeedback wrapping the PDF content in PDFView/index.tsx:133-143. When tapped, it should call handleTap → setShouldShowArrows(prev => !prev) to toggle the carousel arrows.

However, inside the PDF, react-fast-pdf's PDFPreviewer renders a scrollable react-window List container (overflow: auto) and react-pdf's .textLayer (position: absolute; inset: 0; z-index: 2) which covers the entire page with text-selectable spans. On Android Chrome mWeb, these layers intercept touch events (for scrolling and text selection respectively), preventing the tap from propagating up to the parent PressableWithoutFeedback.

Why images work but PDFs don't: Images on touch screens use Lightbox → MultiGestureCanvas → Gesture.Tap() from react-native-gesture-handler, which handles tap detection at a native gesture level that bypasses DOM event propagation issues. PDFs have no such mechanism on web — the web AttachmentViewPdf/index.tsx passes onPress directly to PDFView, bypassing BaseAttachmentViewPdf (which native platforms use and which calls actions.onTap() from context as a secondary toggle path).

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

In PDFView/index.tsx, add an overlay Pressable on top of the PDF content (with a higher z-index) that captures taps and calls onPress, rather than relying on the PressableWithoutFeedback parent wrapper to receive events that bubble up through the PDF layers. This overlay should be transparent and should not block scrolling — it should only respond to tap (not drag/scroll) gestures. Alternatively, use pointerEvents styling to prevent the .textLayer and .annotationLayer from intercepting taps when the PDF is displayed inside the carousel.

What alternative solutions did you explore? (Optional)

1. Make web AttachmentViewPdf/index.tsx use BaseAttachmentViewPdf (like iOS/Android native do) to get the context-based actions.onTap() fallback. This would add the secondary toggle mechanism, but wouldn't fix the underlying event interception — PDFView's PressableWithoutFeedback.onPress would still not fire, so it would only work if the context path fires independently.

2. Add pointer-events: none to .textLayer and .annotationLayer via CSS overrides when rendered inside the carousel. This is simpler but would disable text selection and annotation interaction within PDFs in the carousel.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @twilight2294 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[MobileMage]

Proposal

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

When viewing a PDF attachment in the carousel on Android mWeb (Chrome), tapping the PDF document does not toggle the navigation arrow buttons — they neither appear nor disappear as expected.

What is the root cause of that problem?

The carousel view on web passes an onPress handler (handleTap) down the tree: AttachmentCarouselView → CarouselItem → AttachmentView → AttachmentViewPdf. The web-specific AttachmentViewPdf/index.tsx simply passes onPress straight through to PDFView, which wraps the PDF content in a PressableWithoutFeedback. However, the react-fast-pdf PDFPreviewer element renders its own touch-handling layer that intercepts touch events on mWeb, so the PressableWithoutFeedback's onPress never fires and handleTap (which calls setShouldShowArrows) is never invoked.

The base version of this component (BaseAttachmentViewPdf.tsx) solves this correctly: it reads the carousel pager context and explicitly calls actions.onTap?.() in its own onPress callback, independent of whether the inner PDF element swallows the touch event. BaseAttachmentViewPdf is only used on native (iOS/Android app) via the platform-specific files (index.ios.tsx, index.android.tsx), while the web entry (index.tsx) bypasses the context entirely.

App/src/components/Attachments/AttachmentView/AttachmentViewPdf/index.tsx

Lines 1 to 21 in 7b11ba3

	import React, {memo} from 'react';
	import PDFView from '@components/PDFView';
	import type AttachmentViewPdfProps from './types';
	function AttachmentViewPdf({file, encryptedSourceUrl, isFocused, onPress, onToggleKeyboard, onLoadComplete, style, isUsedAsChatAttachment, onLoadError}: AttachmentViewPdfProps) {
	return (
	<PDFView
	onPress={onPress}
	isFocused={isFocused}
	sourceURL={encryptedSourceUrl}
	fileName={file?.name}
	style={style}
	onToggleKeyboard={onToggleKeyboard}
	onLoadComplete={onLoadComplete}
	isUsedAsChatAttachment={isUsedAsChatAttachment}
	onLoadError={onLoadError}
	/>
	);
	}
	export default memo(AttachmentViewPdf);

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

The web AttachmentViewPdf/index.tsx should be replaced with BaseAttachmentViewPdf. Since BaseAttachmentViewPdf already handles both the case where the carousel context exists (picks up actions.onTap) and the case where it doesn't (falls back to the onPressProp), making the web entry point simply re-export BaseAttachmentViewPdf is the correct and minimal fix.

App/src/components/Attachments/AttachmentView/AttachmentViewPdf/BaseAttachmentViewPdf.tsx

Lines 56 to 67 in 7b11ba3

	const onPress = useCallback(
	(event?: GestureResponderEvent | KeyboardEvent) => {
	if (onPressProp !== undefined) {
	onPressProp(event);
	}
	if (state !== null && actions && isScrollEnabled?.get()) {
	actions.onTap?.();
	}
	},
	[state, actions, isScrollEnabled, onPressProp],
	);

// src/components/Attachments/AttachmentView/AttachmentViewPdf/index.tsx
-import React, {memo} from 'react';
-import PDFView from '@components/PDFView';
-import type AttachmentViewPdfProps from './types';
-
-function AttachmentViewPdf({file, encryptedSourceUrl, isFocused, onPress, onToggleKeyboard, onLoadComplete, style, isUsedAsChatAttachment, onLoadError}: AttachmentViewPdfProps) {
-    return (
-        <PDFView
-            onPress={onPress}
-            isFocused={isFocused}
-            sourceURL={encryptedSourceUrl}
-            fileName={file?.name}
-            style={style}
-            onToggleKeyboard={onToggleKeyboard}
-            onLoadComplete={onLoadComplete}
-            isUsedAsChatAttachment={isUsedAsChatAttachment}
-            onLoadError={onLoadError}
-        />
-    );
-}
-
-export default memo(AttachmentViewPdf);
+export {default} from './BaseAttachmentViewPdf';

This ensures that on web, tapping the PDF document goes through the same context-aware onPress path used on native, which calls actions.onTap?.() to toggle the carousel navigation buttons.

What alternative solutions did you explore? (Optional)

N/A

[anobie]

Proposal

What is the root cause of that problem?

In src/components/PDFView/index.tsx, the PDF content is wrapped in a PressableWithoutFeedback component to handle taps and toggle the navigation arrows. However, on mobile web (mWeb), the PDFPreviewer from the react-fast-pdf library renders a scrollable container and multiple canvas/text layers that intercept touch events. These events are consumed by the inner viewer's own scroll and interaction handling, preventing them from bubbling up to the outer PressableWithoutFeedback. As a result, the onPress callback is never triggered when tapping the PDF document.

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

We should move the tap handling closer to the PDF content to ensure it captures events before they are fully consumed or blocked.

1. In src/components/PDFView/index.tsx, we should add an onClick event handler directly to the View container that wraps the PDFPreviewer. Since this is a web-specific issue, using the onClick prop on the View (which maps to a div on web) will allow us to catch clicks that bubble up from the PDF layers.
2. The onClick handler should trigger the same onPress logic used to toggle the navigation arrows.
3. We can then remove the outer PressableWithoutFeedback wrapper, as the interaction will be handled by the inner container. We should ensure the container remains accessible by keeping the appropriate accessibility roles and labels.

What alternative solutions did you explore? (Optional)

1. Using pointerEvents="none": While this would allow taps to reach the outer wrapper, it would disable all internal PDF functionality like scrolling, text selection, and link clicking.
2. Adding a transparent overlay: This would also block all interactions with the PDF content itself.
3. Modifying the external library: Changing react-fast-pdf to pass through clicks is a more complex and indirect path compared to handling the event bubbling within our own component.