[$250] Receipts in full-screen modal don't utilize available height (smaller than preview)

[m-natarajan]

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.37-9
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @JmillsExpensify
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open an expense thread containing a receipt
2. Click on the receipt (e.g., eReceipt) to open it in full-screen modal
3. Observe the receipt size within the modal

Expected Result:

The receipt should fill the full available height of the full-screen modal, matching or exceeding the preview size for optimal viewing.

Actual Result:

The receipt displays smaller than the preview, not utilizing the full modal height and leaving unused space around it.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

CleanShot.2026-03-13.at.16.00.19.mp4

Recording.2536.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abdulrahuman5196

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022033326136338015192
• Upwork Job ID: 2033326136338015192
• Last Price Increase: 2026-04-14

[MelvinBot]

Proposal

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

When opening an eReceipt in the full-screen attachment modal, it displays at a fixed small size (335×540px) instead of scaling to fill the available modal space. This makes the full-screen view smaller than or equal to the inline preview, defeating the purpose of opening it in a modal.

What is the root cause of that problem?

There are two different rendering paths for eReceipts — one for previews/thumbnails and one for the full-screen modal — and only the preview path applies scaling.

Preview path (works correctly): ReceiptImage → EReceiptWithSizeCalculation → EReceipt. The EReceiptWithSizeCalculation component (src/components/EReceiptWithSizeCalculation.tsx:38-40) measures the container width, computes scaleFactor = containerWidth / 335, and applies transform: scale(scaleFactor) to make the fixed-size EReceipt fill its container.

Full-screen modal path (the bug): AttachmentView at src/components/Attachments/AttachmentView/index.tsx:208-219 renders the EReceipt component directly inside a centered ScrollView — with no scaling wrapper. The EReceipt has a fixed eReceiptContainer style of width: 335, minHeight: 540 (src/styles/index.ts:4074-4078), so it always renders at that small fixed size regardless of available space.

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

In AttachmentView (src/components/Attachments/AttachmentView/index.tsx:208-219), replace the direct EReceipt rendering with EReceiptWithSizeCalculation — the same scaling wrapper already used in the preview/thumbnail path. This will measure the available container space and apply a CSS transform: scale() to make the eReceipt fill the modal.

The ScrollView wrapper can be kept so that on very small screens the eReceipt remains scrollable if needed, but EReceiptWithSizeCalculation should be used inside it instead of the bare EReceipt.

What alternative solutions did you explore? (Optional)

1. Making EReceipt itself responsive (using percentage widths or flex) — rejected because the eReceipt design relies on fixed pixel dimensions for its internal layout (text positioning, background sizing), and EReceiptWithSizeCalculation already solves this via CSS transform scaling.
2. Reducing the pv5/ph2 padding on TransactionReceiptModalContent (line 611) — this would help marginally but doesn't address the core issue of the eReceipt not scaling at all.

---

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

[melvin-bot]

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

[MobileMage]

Proposal

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

When opening a receipt (including eReceipts) in the full-screen modal, the receipt image is smaller than the preview thumbnail it was opened from, leaving unused whitespace around it instead of filling the available modal height.

What is the root cause of that problem?

TransactionReceiptModalContent passes attachmentViewContainerStyles: [styles.pv5, styles.ph2] into AttachmentModalBaseContent. This style is merged directly onto the imageModalImageCenterContainer view, which is the flex container that constrains the receipt's rendered dimensions. The pv5 style applies paddingVertical: 20, eating 40px of height from the container. Since receipt images and eReceipts scale to fill the available space inside that container, the 20px padding on each side artificially caps their maximum rendered size — making the receipt appear smaller than it could be.

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

Lines 593 to 631 in 0a415ed

	const contentProps = useMemo<AttachmentModalBaseContentProps>(
	() => ({
	source,
	originalFileName,
	report,
	headerTitle,
	threeDotsMenuItems,
	isAuthTokenRequired,
	isTrackExpenseAction: isTrackExpenseActionValue,
	isLoading: !transaction && reportMetadata?.isLoadingInitialReportActions,
	shouldShowNotFoundPage,
	shouldShowCarousel: false,
	shouldShowRotateButton: false,
	onDownloadAttachment: allowDownload ? undefined : onDownloadAttachment,
	transaction,
	shouldMinimizeMenuButton: false,
	footerActionButtons,
	customAttachmentContent,
	attachmentViewContainerStyles: [styles.pv5, styles.ph2],
	}),
	[
	source,
	originalFileName,
	report,
	headerTitle,
	threeDotsMenuItems,
	isAuthTokenRequired,
	isTrackExpenseActionValue,
	transaction,
	reportMetadata?.isLoadingInitialReportActions,
	shouldShowNotFoundPage,
	allowDownload,
	onDownloadAttachment,
	footerActionButtons,
	customAttachmentContent,
	styles.pv5,
	styles.ph2,
	],
	);

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

Remove styles.pv5 from the attachmentViewContainerStyles so the container uses the full available height. The horizontal padding (styles.ph2) can stay since horizontal whitespace on wide screens is reasonable and matches the visual design, but the vertical padding is what's causing the height deficit. The fix is a one-line change in TransactionReceiptModalContent.tsx:

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

Line 611 in 0a415ed

attachmentViewContainerStyles: [styles.pv5, styles.ph2],

- attachmentViewContainerStyles: [styles.pv5, styles.ph2],
+ attachmentViewContainerStyles: [styles.ph2],

What alternative solutions did you explore? (Optional)

N/A

[yuvrajangadsingh]

Proposal

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

When opening an eReceipt in the full-screen attachment modal, it renders at its fixed 335x540px size instead of scaling to fill the available space, making it look smaller than the inline preview.

What is the root cause of that problem?

The eReceipt rendering path in src/components/Attachments/AttachmentView/index.tsx:208-218 renders EReceipt directly inside a ScrollView with no scaling at all. The EReceipt component uses a fixed eReceiptContainer style (width: 335, minHeight: 540 at src/styles/index.ts:4082-4086), so it always renders at that small fixed size.

The existing EReceiptWithSizeCalculation component (src/components/EReceiptWithSizeCalculation.tsx:38-40) is not usable here as-is because it computes scale factor based on width only (containerWidth / 335). In the full-screen modal, the container is wide relative to the eReceipt's aspect ratio (335:540 = ~0.62). Width-based scaling in a landscape-ish modal would produce a receipt that overflows vertically. For example, in an 800px wide modal, the scale would be 2.39x, making the receipt ~1290px tall while the modal height might only be ~700px. The ScrollView would then require vertical scrolling to see the whole receipt, which defeats the purpose of a "full-screen view."

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

Modify EReceiptWithSizeCalculation to accept an optional prop (e.g., shouldFitContainer) that, when true, measures both width and height via onLayout and picks Math.min(containerWidth / eReceiptBGHWidth, containerHeight / eReceiptBGHeight) as the scale factor. This ensures the receipt fills the maximum available space without overflowing either dimension.

In src/components/EReceiptWithSizeCalculation.tsx, change the onLayout handler:

const onLayout = (e: LayoutChangeEvent) => {
    const {width, height} = e.nativeEvent.layout;
    const widthScale = width / variables.eReceiptBGHWidth;
    if (shouldFitContainer && height > 0) {
        const heightScale = height / variables.eReceiptBGHeight;
        setScaleFactor(Math.min(widthScale, heightScale));
    } else {
        setScaleFactor(widthScale);
    }
};

Then in src/components/Attachments/AttachmentView/index.tsx:208-218, replace the bare EReceipt + ScrollView with EReceiptWithSizeCalculation using shouldFitContainer:

if (transaction && !hasReceiptSource(transaction) && hasEReceipt(transaction)) {
    return (
        <View style={[styles.flex1, styles.alignItemsCenter, styles.justifyContentCenter]}>
            <EReceiptWithSizeCalculation
                transactionID={transaction.transactionID}
                shouldFitContainer
            />
        </View>
    );
}

The ScrollView can be dropped here since the receipt will always fit within the container bounds. No scrolling needed.

What alternative solutions did you explore? (Optional)

Removing pv5 padding from TransactionReceiptModalContent only recovers ~40px of vertical space but doesn't address the core issue of the eReceipt having no scaling mechanism at all. Using EReceiptWithSizeCalculation without modification would scale by width only, causing vertical overflow in most modal aspect ratios and requiring the user to scroll to see the full receipt.

[neerajbachani]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

📣 @neerajbachani! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[github-actions]

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