[$250] Attachment - Landscape pdf file preview is truncated in "Share to Expensify" page

[lanitochka17]

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.68-1
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://github.com/Expensify/Mobile-Expensify/pull/13931
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: Samsung Galaxy A52 / Android 14, iPhone 13 / iOS 26.5
App Component: Other

Action Performed:

Preconditions

• Logged in to any user

Steps:

1. Open any pdf file viewer that contains landscape layout (can use the attached file here)
2. Share to Expensify
3. Switch to "Share" tab
4. Choose any recipient
5. Observe the pdf preview in "Share to Expensify" page

Expected Result:

Landscape pdf file preview shouldn't be truncated in "Share to Expensify" page

Actual Result:

Landscape pdf file preview is truncated in "Share to Expensify" page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7147079_1778151241664.pdf_share.mov

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022052347603081138830
• Upwork Job ID: 2052347603081138830
• Last Price Increase: 2026-05-21

[MelvinBot]

Proposal

What is the root cause of that problem?

The PDF thumbnail container in AttachmentPreview.tsx:116 has a hardcoded {aspectRatio: 1} (square), and the PDF is rendered with fitPolicy={1} (fit-width) at line 123. When a landscape PDF is scaled to fill the width of a square container, its height exceeds the container bounds and gets clipped by the overflowHidden styles on the PDFThumbnail wrapper.

Unlike images (which use the actual aspectRatio prop from the shared file on an inner View at line 101), the PDF branch ignores the aspectRatio prop entirely. Additionally, the native share handler modules don't compute aspect ratios for PDFs — Android defaults to 0.0 (ShareActionHandlerModule.kt:54) and iOS defaults to 1.0 (RCTShareActionHandlerModule.m:64).

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

Change fitPolicy from 1 (fit-width) to 0 (fit both dimensions) in AttachmentPreview.tsx:123. fitPolicy=0 tells react-native-pdf to scale the page to fit entirely within the container (both width and height), so a landscape PDF will be fully visible inside the square thumbnail instead of overflowing and getting clipped.

What alternative solutions did you explore? (Optional)

An alternative would be computing the actual PDF aspect ratio in the native share handler modules (Android and iOS) and then using it to size the container dynamically — similar to how images work. This would eliminate letterboxing but is significantly more complex (requires native PDF page-dimension APIs on both platforms) and may not be worth the effort for a thumbnail preview.

---

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 - @rojiphil (External)

[melvin-bot]

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

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-14 17:15:22 UTC.

Proposal

What is the root cause of that problem?

AttachmentPreview shapes its preview container per attachment type, and the PDF branch is the only one that drops the aspectRatio prop entirely.

• The video branch (AttachmentPreview.tsx#L59-L88) and the image branch (AttachmentPreview.tsx#L91-L110) both size an inner View from the real aspectRatio prop — fillStyle + {aspectRatio} — so the media always renders fully inside the square PressableWithFeedback.
• The PDF branch (AttachmentPreview.tsx#L112-L131) ignores aspectRatio, hard-codes {aspectRatio: 1}, and hands sizing to react-native-pdf via fitPolicy={1} (fit-height). Inside a square box, fit-height scales a landscape page until its height fills the box, so its width spills past the right edge and is clipped by styles.overflowHidden on the PDFThumbnail wrapper (PDFThumbnail/index.native.tsx#L18).

The PDF branch can't use aspectRatio because it is never populated for PDFs in the first place. ShareTempFile.aspectRatio is filled by the native share handlers, and both only handle images and videos:

• iOS — aspectRatio defaults to 1.0 and is only overwritten for video/ and image/ MIME types (RCTShareActionHandlerModule.m#L68-L101); a PDF keeps 1.0.
• Android — aspectRatio defaults to 0.0f and is only overwritten for image/ and video/ (ShareActionHandlerModule.kt#L54-L81); a PDF keeps 0.0f.

So a shared PDF reaches AttachmentPreview with a meaningless aspect ratio (1.0 on iOS, 0.0 on Android), the PDF branch couldn't shape itself from it even if it tried, and the page is left to fitPolicy inside a fixed square — which clips whenever the page is wider than tall. This also explains why the truncation is not reliably reproducible: with no real ratio, how badly a given page overflows depends entirely on that page's own proportions and react-native-pdf's fit measurement, so some landscape PDFs clip visibly and others barely do.

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

Finish the aspectRatio wiring that already exists for images and videos, so the PDF branch becomes consistent with them. Two halves — both required, because the JS half alone would collapse the preview on Android (a PDF still carries aspectRatio = 0.0f there).

1. Compute a real aspect ratio for PDFs in the native share handlers, mirroring the existing imageAspectRatio / videoAspectRatio helpers.

iOS — add a pdfAspectRatio: helper and one else if branch in processSingleFile: (RCTShareActionHandlerModule.m#L83-L89):

} else if ([mimeType isEqualToString:@"application/pdf"]) {
    aspectRatio = [self pdfAspectRatio:fileURL];
}

- (CGFloat)pdfAspectRatio:(NSURL *)url {
    CGPDFDocumentRef document = CGPDFDocumentCreateWithURL((__bridge CFURLRef)url);
    if (!document) { return 1; }
    CGPDFPageRef page = CGPDFDocumentGetPage(document, 1);
    CGFloat ratio = 1;
    if (page) {
        CGRect box = CGPDFPageGetBoxRect(page, kCGPDFCropBox);
        CGFloat w = box.size.width, h = box.size.height;
        NSInteger rotation = CGPDFPageGetRotationAngle(page);
        if (rotation == 90 || rotation == 270) { CGFloat t = w; w = h; h = t; }
        ratio = h != 0 ? w / h : 1;
    }
    CGPDFDocumentRelease(document);
    return ratio;
}

Android — add one else if branch alongside the image/video ones (ShareActionHandlerModule.kt#L58-L74) (PdfRenderer / ParcelFileDescriptor need importing):

} else if (mimeType == "application/pdf") {
    try {
        ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_ONLY).use { pfd ->
            PdfRenderer(pfd).use { renderer ->
                if (renderer.pageCount > 0) {
                    renderer.openPage(0).use { page ->
                        aspectRatio = if (page.height != 0) page.width.toFloat() / page.height else 1.0f
                    }
                }
            }
        }
    } catch (e: Exception) {
        Log.e("ShareActionHandlerModule", "Error reading pdf dimensions: ${e.message}")
        aspectRatio = 1.0f
    }
}

Both fall back to 1 on failure, exactly like imageAspectRatio does today.

2. Make the PDF branch consume aspectRatio the way the image branch does — wrap PDFThumbnail in an aspect-ratio'd View (reusing the fillStyle already computed at AttachmentPreview.tsx:37) instead of leaving it unconstrained:

     if (typeof source === 'string' && Str.isPDF(source) && !isEncryptedPDF) {
         return (
             <PressableWithFeedback
                 accessibilityRole="button"
                 style={[styles.justifyContentStart, {aspectRatio: 1}]}
                 onPress={onPress}
                 accessible
                 accessibilityLabel="PDF Thumbnail"
                 sentryLabel={CONST.SENTRY_LABEL.ATTACHMENT_PREVIEW.PDF_THUMBNAIL}
             >
-                <PDFThumbnail
-                    fitPolicy={1}
-                    previewSourceURL={source}
-                    style={[styles.br4]}
-                    onLoadError={onLoadError}
-                    onPassword={() => setIsEncryptedPDF(true)}
-                />
+                <View style={[fillStyle, styles.br4, styles.overflowHidden, {aspectRatio}]}>
+                    <PDFThumbnail
+                        fitPolicy={2}
+                        previewSourceURL={source}
+                        style={[styles.w100, styles.h100]}
+                        onLoadError={onLoadError}
+                        onPassword={() => setIsEncryptedPDF(true)}
+                    />
+                </View>
             </PressableWithFeedback>
         );
     }

Now the PDF lands in a container whose shape matches the page — a landscape page gets a wide-but-short box (fillStyle = styles.w100, aspectRatio > 1), a portrait page gets a tall-but-narrow box — both fully inside the square PressableWithFeedback, identical to how the image branch already behaves. styles.w100/h100 on PDFThumbnail makes its wrapper actually fill that box (today it only gets styles.br4, so it is never constrained to its parent), and fitPolicy={2} (fit-both) is now purely defensive since the container already carries the correct ratio. There is no new prop on PDFThumbnail and no post-load relayout — the ratio travels with the shared file, so it is known before the component mounts.

What alternative solutions did you explore? (Optional)

• Only flip fitPolicy={1} → fitPolicy={2} and keep the square container. It stops the clipping, but a wide landscape page then renders as a thin strip stranded in a large empty square — no longer truncated but still wrong, and it leaves the PDF branch inconsistent with the image/video branches.
• Read the page size on the JS side via react-native-pdf's onLoadComplete {width, height} and lift it into local state to reshape the wrapper. This works, but it introduces a visible post-mount layout shift (the preview resizes once the PDF resolves), needs a new callback plumbed through PDFThumbnail, and leaves ShareTempFile.aspectRatio permanently dead for PDFs — diverging further from the existing pipeline instead of completing it.
• Web parity: the web PDFThumbnail (PDFThumbnail/index.tsx) does not accept fitPolicy and renders <Thumbnail> at intrinsic size, so a landscape page can still overflow there. This issue is scoped to Android/iOS App; the AttachmentPreview.tsx wrapper above already shapes the container correctly on web too, and constraining the web <Thumbnail width=…> can follow as a small separate change if needed.

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

The PDF preview rendered on the share details page is forced into a square frame with react-native-pdf's "fit height" policy. In AttachmentPreview.tsx the PDF branch wraps <PDFThumbnail/> in a square container and passes fitPolicy={1}:

return (
    <PressableWithFeedback
        ...
        style={[styles.justifyContentStart, {aspectRatio: 1}]}
    >
        <PDFThumbnail
            fitPolicy={1}
            previewSourceURL={source}
            ...
        />
    </PressableWithFeedback>
);

react-native-pdf's fit policies are: 0 = fit width, 1 = fit height, 2 = fit both (preserve aspect ratio). With fitPolicy={1} the page is scaled so its height matches the container; for a landscape PDF whose width is greater than its height, the scaled width exceeds the square container's width and gets clipped by the parent's overflow: hidden (PDFThumbnail/index.native.tsx#L17-L48).

The aspectRatio prop that AttachmentPreview receives can't compensate for this on its own: for non-image / non-video files the iOS share handler hard-codes aspectRatio = 1.0 (see ios/RCTShareActionHandlerModule.m#L68-L101), and the image branch above is the only place that actually shapes the wrapper from that value — the PDF branch ignores it. So every shared PDF lands in a 1:1 frame regardless of orientation.

The web path has the analogous problem: PDFThumbnail/index.tsx#L13-L60 renders <Thumbnail/> at its intrinsic page size inside overflow: hidden, so a landscape page wider than the container is clipped on the sides.

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

I'd switch the share preview to "fit both" so the PDF scales while preserving its aspect ratio, and forward that intent to the web thumbnail.

                 <PDFThumbnail
-                    fitPolicy={1}
+                    fitPolicy={2}
                     previewSourceURL={source}
                     style={[styles.br4]}
                     onLoadError={onLoadError}
                     onPassword={() => setIsEncryptedPDF(true)}
                 />

For portrait PDFs this is a no-op (height is the limiting dimension either way); for landscape PDFs the width becomes the limiting dimension and the page renders fully inside the square frame with a small vertical letterbox instead of being clipped.

Supporting changes:

• In src/components/PDFThumbnail/index.tsx (web), respect fitPolicy by passing width={containerWidth} (measured via onLayout) to <Thumbnail/> when fitPolicy === 2. That makes the canvas honor the parent container width and scale the height proportionally, which mirrors the native behavior. The portrait case still fits because the canvas gets scaled down rather than rendering at intrinsic size.
• Optional polish: in AttachmentPreview.tsx PDF branch, swap the wrapper's hardcoded {aspectRatio: 1} for {aspectRatio} when an aspect ratio is known (today only iOS image/video paths populate it), so future native handlers that emit a real PDF aspect ratio get a properly-shaped frame for free.

What alternative solutions did you explore?

1. Read the PDF's natural size on load and resize the wrapper to match. Cleanest visually, but requires plumbing onLoadSuccess dimensions out of both react-native-pdf and react-pdf, plus a re-layout pass. More moving parts than the bug warrants.
2. Compute aspect ratio in the native share handlers (ios/RCTShareActionHandlerModule.m, Android equivalent) and pass it through ShareTempFile.aspectRatio. Fixes the wrapper shape at the source, but it's a multi-platform native change for what is really a render-policy bug — the fitPolicy={2} flip handles it without touching native code.
3. Use fitPolicy={0} (fit width) instead of fitPolicy={2}. Works for landscape, but inverts the bug for portrait PDFs taller than the container — they'd get vertically clipped. fitPolicy={2} is the only choice that's safe for both orientations.

[oqildev]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

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