[$250] Scan - Crop option not displayed for PDF Receipts

[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: 9.3.61-0
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/test-runs/TR-21013/folder/13176933/41237706/1356325665?sort=%2Bidentifier
Email or phone of affected tester (no customers): jsat@applausemail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Macbook Pro/iOS 13.7.8
App Component: Other

Action Performed:

1. Launch Expensify App
2. Log in with valid credentials
3. Create or open an expense
4. Upload a PDF receipt
5. Click on the receipt thumbnail

Expected Result:

"Rotate", "Crop" and "Replace" options are displayed beneath the receipt

Actual Result:

"Crop" option not displayed for PDF Receipts

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7134909_1776777704439.web-repro.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mollfpr

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022046585844476803674
• Upwork Job ID: 2046585844476803674
• Last Price Increase: 2026-04-28

[MelvinBot]

Proposal

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

When viewing a PDF receipt, the "Crop" option is missing from the receipt action buttons — only "Rotate" and "Replace" are shown. The expected behavior is that "Rotate", "Crop", and "Replace" are all displayed.

What is the root cause of that problem?

The Crop button visibility is controlled by shouldShowRotateAndCropReceiptButton, which requires isImage to be true. Since isImage is derived from Str.isImage(fileName), it's always false for PDF files — so the Crop button never renders for PDFs.

PDF Rotate works because it has a separate rendering path gated on isPDF && !isNative. Replace works because shouldShowReplaceReceiptButton has no isImage requirement. There is no analogous PDF-specific Crop path.

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

The underlying crop utility (cropOrRotateImage) uses expo-image-manipulator, which only handles raster images. To support PDF crop:

1. Render the PDF page to an image first, then crop the resulting image. When the user taps "Crop" on a PDF receipt, convert the current PDF page to a raster image (e.g., using a canvas-based approach on web, or a native PDF-to-image utility), then pass it through the existing cropOrRotateImage flow.

2. Add a Crop button for PDFs in TransactionReceiptModalContent.tsx alongside the existing PDF Rotate button (around line 537). This button would trigger the PDF-to-image conversion followed by the crop modal.

3. Create a shouldShowCropButton condition (or broaden the existing shouldShowRotateAndCropReceiptButton) that includes PDFs, separate from the image-only rotate logic.

Investigation details

Key code locations:

• shouldShowRotateAndCropReceiptButton with isImage gate: TransactionReceiptModalContent.tsx:346-354
• isImage / isPDF definitions: TransactionReceiptModalContent.tsx:158-159
• PDF-only Rotate button: TransactionReceiptModalContent.tsx:537-544
• cropOrRotateImage (image-only): cropOrRotateImage/index.ts:1-32

Data flow:

1. Receipt modal opens → isImage = false, isPDF = true for PDF files
2. shouldShowRotateAndCropReceiptButton → false (because isImage is false)
3. Image Rotate + Crop buttons (lines 519-536) → hidden
4. PDF Rotate button (line 537) → shown via isPDF && !isNative
5. Replace button (line 545) → shown (no isImage requirement)
6. Result: PDF receipts show only Rotate + Replace

Note: PDF Rotate is purely cosmetic (rotates the display via state), unlike image Rotate which creates a new rotated file. A proper Crop for PDFs would need to produce a new file.

---

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

[melvin-bot]

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

[alexanderxfgl-bit]

Proposal

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

The crop option is not displayed for PDF receipts in the Expensify app.

What is the root cause of that problem?

The cropImageToAspectRatio function (src/pages/iou/request/step/IOURequestStepScan/cropImageToAspectRatio.ts:42) is only designed to handle 'image/jpeg' files. When a PDF receipt is uploaded, this function is not called, and therefore the cropping options are not displayed. The code implicitly assumes all images are JPEGs, failing to account for other formats like PDFs.

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

Modify the cropImageToAspectRatio function to handle PDF files. This can be done by removing the type check or adding a condition to process PDFs as well. This will ensure that the cropping functionality is triggered for PDF receipts, and the "Crop" option becomes visible.

What alternative solutions did you explore? (Optional)

N/A

[alexanderxfgl-bit]

Contributor details
Your Expensify account email: alexanderxfgl@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~2021935202864784599

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[alexanderxfgl-bit]

Compare branch with the fix: https://github.com/Expensify/App/compare/main...alexanderxfgl-bit/App:fix/88432-ai?expand=1

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-24 09:19:44 UTC.

Proposal

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

When a PDF receipt is opened from an expense, the receipt-action toolbar only shows Rotate and Replace. The Crop button is missing, so users cannot crop PDF receipts from the receipt view even though the expected behavior is to show Rotate, Crop, and Replace.

What is the root cause of that problem?

TransactionReceiptModalContent couples Crop to the image-only Rotate path. The shared shouldShowRotateAndCropReceiptButton condition requires isImage to be true, so PDFs skip the whole block that renders the image Rotate and Crop buttons. PDF Rotate still appears because it is rendered separately behind isPDF && !isNative, and Replace appears because it is not gated by isImage.

There is a second image-only assumption in the crop pipeline: sourceUri is prepared only for image receipts, and saveCrop() exits unless isImage is true. So simply showing the Crop button for PDFs would still be incomplete.

The missing piece is that saved PDF receipts already have a server-generated JPEG thumbnail available via getThumbnailAndImageURIs(). For PDFs, ReceiptUtils returns a .jpg.1024.jpg thumbnail next to the original PDF source, but the receipt modal does not use that raster thumbnail as the crop source.

App/src/pages/media/AttachmentModalScreen/routes/TransactionReceiptModalContent.tsx

Lines 184 to 203 in 4cfb6a6

	useEffect(() => {
	if (!source || !isImage) {
	return;
	}
	if (!isAuthTokenRequired || typeof source !== 'string') {
	setSourceUri(source);
	return;
	}
	if (!session?.encryptedAuthToken) {
	return;
	}
	fetchImage(source, session?.encryptedAuthToken)
	.then((uri) => {
	setSourceUri(uri);
	})
	.catch(() => setSourceUri(''));
	}, [source, isAuthTokenRequired, session?.encryptedAuthToken, isDraftTransaction, isImage]);

App/src/pages/media/AttachmentModalScreen/routes/TransactionReceiptModalContent.tsx

Lines 349 to 357 in 4cfb6a6

	const shouldShowRotateAndCropReceiptButton = useMemo(
	() =>
	shouldShowReplaceReceiptButton &&
	transaction &&
	(hasReceiptSource(transaction) || (isOdometerImage && hasOdometerImageSource(transaction, imageType))) &&
	!isEReceipt &&
	!transaction?.receipt?.isTestDriveReceipt &&
	isImage,
	[shouldShowReplaceReceiptButton, transaction, isEReceipt, isOdometerImage, imageType, isImage],

App/src/libs/ReceiptUtils.ts

Lines 79 to 85 in 4cfb6a6

	if (isReceiptPDF && typeof path === 'string') {
	return {
	thumbnail: `${path.substring(0, path.length - 4)}.jpg.1024.jpg`,
	thumbnail320: `${path.substring(0, path.length - 4)}.jpg.320.jpg`,
	image: path,
	filename,
	};

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

Use the existing PDF thumbnail as the crop input, and decouple Crop from image Rotate.

Concrete changes:

1. Derive a receiptThumbnailSource from receiptURIs.thumbnail, resolving it through tryResolveUrlFromApiRoot() for remote receipts.
2. Derive cropSource separately from the preview source: images continue using the receipt image source, while PDFs use the JPEG thumbnail source.
3. Update the existing sourceUri preparation effect to fetch/cache cropSource for both images and PDFs, instead of only preparing sources when isImage is true.
4. Split the old shared shouldShowRotateAndCropReceiptButton gate into separate gates:
   • image Rotate remains image-only, because it writes a rotated image file;
   • Crop is shown for images and for PDFs that have a thumbnail crop source.
5. Remove the isImage guard from saveCrop() and allow the PDF-thumbnail crop path. For cropped PDFs, save the output as a JPEG filename/type so the updated receipt is treated as an image after crop.
6. For draft transactions, persist the cropped file's actual MIME type instead of reusing the original receipt type, so a cropped PDF draft is stored as image/jpeg rather than application/pdf.

This keeps the fix inside TransactionReceiptModalContent.tsx and reuses the existing fetchImage(), ReceiptCropView, cropOrRotateImage(), and receipt replacement flow. It avoids adding a new cross-platform PDF rasterization subsystem.

What alternative solutions did you explore? (Optional)

• Only loosen the isImage button gate. This is incomplete because sourceUri and saveCrop() are still image-only, so Crop could render but fail for PDFs.
• Add a full PDF rasterization helper using pdfjs, react-native-pdf, and captureRef. This works in principle, but it is higher cost and riskier than necessary because saved PDF receipts already expose a JPEG thumbnail through ReceiptUtils.
• Modify IOURequestStepScan/cropImageToAspectRatio. That helper belongs to the scan/capture flow, not this receipt modal, so it would not add the missing toolbar action or route saved PDF receipts through the crop UI.

Comparison branch for proof of fix :- https://github.com/Expensify/App/compare/main...KJ21-ENG:App:kj21-88432-pdf-crop-receipt?expand=1

Proof of working fix :-

1776784621285343.mp4