[Due for payment 2026-07-21] [$250] mWeb-the PDF file can't be zoomed in

[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.3.89-3
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): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 iOS 26.5 Safari
App Component: Chat Report View

Action Performed:

1. Navigate to staging.new.expensify.com and sign in
2. Navigate to the Inbox, tap grey "+" button - Start chat
3. Enter another existing user's email, send a PDF file in the chat
4. Tap the PDF file preview, pinch the file to zoom

Expected Result:

User can pinch the PDF file to zoom

Actual Result:

PDF file cannot be pinched/ zoomed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166509_1780072744711.Can_t_zoom_the_PDF.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060432855074052895
• Upwork Job ID: 2060432855074052895
• Last Price Increase: 2026-06-26

Issue Owner

Current Issue Owner: @nyomanjyotisa

[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/44bf6ad82a1189c2cb41d65d3e0da2aea15c2ce777e25e89e78e7b9929facac7

[MelvinBot]

Proposal

What is the root cause of that problem?

On web/mWeb, PDF attachments have no in-app pinch-zoom implementation, while the App globally disables the browser's native pinch-zoom. The two combine to make PDFs un-zoomable on iOS Safari, which strictly enforces both gates.

Two conditions together:

1. The web PDF path (AttachmentView → AttachmentViewPdf → PDFView/index.tsx) renders react-fast-pdf's PDFPreviewer inside a plain <View> — there is no Gesture, PanResponder, MultiGestureCanvas, or onScaleChanged wired up. Compare with the native iOS path which explicitly wraps the PDF in Gesture.Pan() from react-native-gesture-handler, and with the native PDFView which forwards onScaleChanged to react-native-pdf.

2. The browser's native pinch-zoom is globally suppressed in web/index.html: * { touch-action: pan-x pan-y; } (universal selector excludes the pinch-zoom action) plus body { touch-action: none; }, alongside <meta name="viewport" content="... user-scalable=no ...">. iOS Safari strictly honors both, so two-finger pinch gestures are dropped before they reach any handler.

Images do not exhibit this bug because they are routed through Lightbox → MultiGestureCanvas, which captures pinch in JS via react-native-gesture-handler (sidestepping the disabled browser-native pinch). PDFs never enter that path on web.

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

Wrap the web PDFView in the same JS-driven gesture stack already used for images, so the App captures pinch gestures regardless of the browser's blocked native pinch.

Concretely, in App/src/components/PDFView/index.tsx:

• Wrap the rendered <PDFPreviewer> (or the outer container around it) in a MultiGestureCanvas (or compose with the Lightbox pattern) configured with pinch + pan gestures, similar to how ImageView uses it for images.
• Forward an onScaleChanged callback up through BaseAttachmentViewPdf so the existing AttachmentCarouselPagerContext pager-scroll suppression (already plumbed for native at BaseAttachmentViewPdf.tsx) also fires on web while zooming.
• Note that react-fast-pdf's internal innerContainer sets overflow: hidden, so the transformed gesture canvas should sit outside that container (wrapping PDFPreviewer, not nested inside it) to avoid clipping the zoomed content.

What alternative solutions did you explore? (Optional)

Re-enabling browser-native pinch on the PDF subtree only (touch-action: pinch-zoom on the PDFView container). Rejected because: (a) the universal * { touch-action: pan-x pan-y; } rule in web/index.html would need to be overridden with higher specificity or !important, (b) <meta user-scalable=no> is still in effect for the page and iOS Safari honors it, and (c) react-fast-pdf's overflow: hidden inner container would clip any user-agent zoom transform. The gesture-handler approach is cleaner, mirrors the existing image-zoom architecture, and keeps the pager interaction consistent.

Investigation details

Evidence chain (HEAD d332c6b):

• Web PDF render path is AttachmentView → AttachmentViewPdf/index.tsx (thin pass-through) → PDFView/index.tsx → PDFPreviewer (from react-fast-pdf). No gesture/zoom handler exists at any level on web.
• Image render path is AttachmentView → AttachmentViewImage → ImageView → Lightbox → MultiGestureCanvas (JS-driven pinch via react-native-gesture-handler).
• iOS-only wrapper AttachmentViewPdf/index.ios.tsx handles native iOS gestures but is not loaded in the web bundle for mWeb Safari.

Why iOS Safari specifically (and not Android Chrome): Android Chrome historically applies an accessibility override that can ignore user-scalable=no, while iOS Safari strictly enforces both user-scalable=no and the touch-action allow-list. So the App's universal touch-action: pan-x pan-y plus user-scalable=no cleanly blocks pinch on iOS but leaks through on Android Chrome. The bug report flags iOS mWeb Safari only, which is consistent with this gating behavior.

Confidence: High — static evidence is conclusive (no in-app pinch handler on web PDF path + globally disabled browser pinch), and the symptom-platform mapping is consistent with documented iOS Safari behavior.

---

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

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-29 18:47:54 UTC.

Proposal

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

When a PDF attachment is opened in the attachment viewer on iOS mWeb Safari, the user cannot pinch-to-zoom the PDF. The exact same flow works on iOS native App, iOS mWeb Chrome, Android, and all desktop browsers — pinch-zoom only fails on iOS mWeb Safari specifically.

What is the root cause of that problem?

On web, the PDF attachment viewer has no in-app pinch-zoom implementation at all. AttachmentView routes PDFs to AttachmentViewPdf → PDFView, and the web PDFView renders the document with react-fast-pdf's PDFPreviewer, which paints react-pdf canvas pages inside a react-window virtualized list. Images get wrapped in Lightbox/MultiGestureCanvas (which implements pinch via react-native-gesture-handler), and the avatar path passes enableMultiGestureCanvas, but PDFs get neither — the PDFPreviewer tree contains no gesture canvas and no pinch handler:

App/src/components/PDFView/index.tsx

Lines 94 to 130 in d332c6b

	return (
	<View
	style={outerContainerStyle}
	tabIndex={0}
	>
	<PDFPreviewer
	contentContainerStyle={style as CSSProperties}
	file={sourceURL}
	pageMaxWidth={variables.pdfPageMaxWidth}
	isSmallScreen={shouldUseNarrowLayout}
	maxCanvasWidth={maxCanvasWidth}
	maxCanvasHeight={maxCanvasHeight}
	maxCanvasArea={maxCanvasArea}
	LoadingComponent={
	<LoadingIndicator
	style={
	isUsedAsChatAttachment && [
	styles.chatItemPDFAttachmentLoading,
	StyleUtils.getWidthAndHeightStyle(LOADING_THUMBNAIL_WIDTH, LOADING_THUMBNAIL_HEIGHT),
	styles.pRelative,
	]
	}
	/>
	}
	shouldShowErrorComponent={false}
	onLoadError={onLoadError}
	rotation={rotation}
	renderPasswordForm={({isPasswordInvalid, onSubmit, onPasswordChange}) => (
	<PDFPasswordForm
	isFocused={!!isFocused}
	isPasswordInvalid={isPasswordInvalid}
	onSubmit={onSubmit}
	onPasswordUpdated={onPasswordChange}
	/>
	)}
	/>
	</View>

Because there is no app-level pinch handling, zooming a PDF on web depends entirely on the browser's native pinch-to-zoom of the page. That native gesture is globally disabled by the viewport meta tag, which sets user-scalable=no:

App/web/index.html

Line 151 in d332c6b

<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1, interactive-widget=resizes-content, viewport-fit=cover">

That single attribute is the whole bug. The reason it manifests only on iOS Safari — and not iOS Chrome, even though both run WebKit — is a browser-policy difference: since Chrome 48, Blink (and therefore Chrome/CriOS) deliberately ignores user-scalable=no so users can always zoom for accessibility, whereas Safari strictly honors it. The app's own isMobileSafari() helper encodes exactly this distinction, matching iP(ad|od|hone) + WebKit but excluding CriOS/FxiOS/OPiOS:

return /iP(ad|od|hone)/i.test(userAgent) && /WebKit/i.test(userAgent) && !/(CriOS|FxiOS|OPiOS|mercury)/i.test(userAgent);

This explains the entire affected-platform matrix: iOS Safari honors user-scalable=no → blocked; iOS Chrome ignores it → works; native apps use their own gesture handling rather than the browser → work; desktop browsers zoom via keyboard/trackpad, which user-scalable does not gate → work.

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

We should re-enable user scaling only while a PDF attachment is open, and only on iOS mWeb Safari, by dynamically swapping the viewport meta tag and restoring it on unmount. Globally dropping user-scalable=no from web/index.html is too broad — it would re-enable accidental double-tap/pinch zoom across the entire app UI on every browser, which is why that attribute exists. A scoped, self-cleaning effect keeps the global behavior intact and touches nothing outside the PDF case. We can gate on the existing isMobileSafari() helper from src/libs/Browser (which already excludes iOS Chrome) so the change is a true no-op everywhere else, and add a small web-only hook mounted by PDFView that toggles the meta content:

// web-only effect inside PDFView (index.tsx)
useEffect(() => {
    if (!isMobileSafari()) {
        return;
    }
    const meta = document.querySelector('meta[name="viewport"]');
    const original = meta?.getAttribute('content') ?? '';
    meta?.setAttribute('content', original.replace('user-scalable=no', 'user-scalable=yes, maximum-scale=5'));
    return () => meta?.setAttribute('content', original);
}, []);

Because this lives in src/components/PDFView/index.tsx (the web entry, with a no-op index.native.tsx counterpart) it scopes the override to exactly the PDF viewer lifecycle, restores the original user-scalable=no the moment the viewer closes, and leaves images, the rest of the app, and all non-Safari browsers completely unaffected.

What alternative solutions did you explore? (Optional)

The "correct" long-term fix would be to wrap the web PDF in MultiGestureCanvas so pinch is handled in-app like images are, giving identical behavior on every browser; I rejected it as the primary fix because the PDF renders as a virtualized, internally-scrolling react-window list, so nesting it in a pan/pinch canvas would fight the existing scroll/pager gestures and risk regressions on already-working platforms — a far larger and riskier change than re-enabling the native gesture Safari is uniquely suppressing.

[melvin-bot]

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

[melvin-bot]

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

[oqildev]

Proposal

What is the root cause of that problem?

On web/mWeb, PDFs are rendered by react-fast-pdf's PDFPreviewer, which PDFView mounts here: src/components/PDFView/index.tsx#L99-L106. I grepped the whole react-fast-pdf@1.0.33 source — PDFPreviewer.tsx, PageRenderer.tsx, everything — and there is no pinch / zoom / scale-gesture code at all. It renders pages into a react-window virtualized list at a fixed pageMaxWidth and lets you scroll. That's it. So on the web stack, zooming a PDF depends entirely on the browser's native pinch-to-zoom.

That's the difference from images, which never hit this bug: images go through MultiGestureCanvas and get JS-driven pinch zoom from react-native-gesture-handler (usePinchGesture.ts). PDFs on web have no equivalent — the web AttachmentViewPdf just forwards straight to PDFView with no gesture wrapper (AttachmentViewPdf/index.tsx#L7-L20).

And the app disables the browser's native pinch-zoom globally, in two places in web/index.html:

• Every element gets touch-action: pan-x pan-y (web/index.html#L42-L43). pan-x pan-y deliberately omits pinch-zoom, so the browser won't interpret a two-finger gesture over the PDF as a zoom — this is the operative blocker on iOS Safari (which otherwise ignores user-scalable=no).
• The viewport is user-scalable=no (web/index.html#L131).

So: no JS zoom for the web PDF + native zoom suppressed by touch-action/viewport = the PDF can't be pinched on mWeb. This is a longstanding gap, not a recent regression — both index.html lines have been in place since 9.1.13 (March 2025), and PDFPreviewer has never shipped zoom.

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

Fix layer: style/config, scoped to the PDF preview subtree — re-enable the browser's native pinch-zoom only over the PDF, instead of trying to bolt JS zoom onto a virtualized list.

Concretely, give the PDF container in renderPDFView (src/components/PDFView/index.tsx#L91-L132) and the PressableWithoutFeedback wrapper (#L134-L147) touch-action: pinch-zoom (web-only style), overriding the global * { touch-action: pan-x pan-y }. touch-action isn't inherited, so the rule also has to reach the descendant canvas/scroll nodes that react-fast-pdf renders — easiest via a class on the outer View plus a [class] * { touch-action: pinch-zoom } rule in web/index.html. On iOS Safari this restores the visual-viewport pinch over the PDF, which is exactly the "pinch the file to zoom" the tester expects.

Edge cases this actually touches: the onPress tap-to-toggle path stays intact (pinch-zoom still allows taps; if single-finger panning regresses, use manipulation-plus-pinch-zoom semantics by allowing pan too). No Onyx/offline/optimistic surface here — it's render/style only.

I'd leave the global viewport user-scalable=no alone; touching it changes zoom behavior app-wide and isn't needed since iOS Safari ignores it anyway.

What alternative solutions did you explore? (Optional)

Wrap the web PDF in MultiGestureCanvas for JS-driven zoom (like images). Structurally different — it'd give in-modal zoom consistent with images and work on every browser, not just iOS Safari. Rejected as the primary fix: PDFPreviewer renders pages in a react-window VariableSizeList that measures and virtualizes by pixel width (PDFPreviewer.tsx#L120-L145); a transform: scale wrapper fights that virtualization (blurry re-rasterization, broken hit-testing/scroll math). Doing it properly means adding a scale prop upstream in react-fast-pdf, which is a much larger change than this bug warrants. Worth filing as a follow-up if we want cross-browser PDF zoom parity.

Flip the global user-scalable=no to allow scaling. Rejected: it's a whole-app config change that re-enables page zoom everywhere and risks layout regressions across the product, and it wouldn't even be the deciding factor on iOS Safari (which ignores it) — the touch-action rule is what actually blocks the gesture.

[github-actions]

⚠️ @oqildev 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.

[oqildev]

My Proposal is not duplicate. I posted first after Help Wanted Label.