Defer image loading and use original receipt image by bernhardoj · Pull Request #97313 · Expensify/App

bernhardoj · 2026-07-29T08:19:15Z

Explanation of Change

Fixed Issues

$ #96999
PROPOSAL:

Tests

Same as QA Steps

Verify that no errors appear in the JS console

Offline tests

Same as QA Steps

QA Steps

Prerequisite: have multiple expenses with receipts, small and large images

Open the expenses one by one
Observe the receipt image
Verify it will load the lower-res image first with a loading and dimmed image
Verify it shows the original image after the loading is done
(WEB only) Hover over the image
Verify the original image is zoomed

large image.jpg

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

web.mp4

codecov · 2026-07-29T08:23:06Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/components/DeferredImageWithLoading.tsx	`100.00% <100.00%> (ø)`
src/components/ImageWithLoading.tsx	`73.52% <100.00%> (-0.76%)`	⬇️
src/components/ImageWithSizeCalculation.tsx	`100.00% <100.00%> (ø)`
src/components/ReceiptImage/index.tsx	`68.88% <0.00%> (ø)`
...ponents/ReportActionItem/ReportActionItemImage.tsx	`70.96% <0.00%> (-1.17%)`	⬇️
... and 15 files with indirect coverage changes

github-actions · 2026-07-29T09:24:17Z

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

dubielzyk-expensify · 2026-07-29T23:14:11Z

I'm unsure if I'm testing it right, but it looks blurry then it loads in the unpixelated one is that correct?

It doesn't feel horrible or anything. I wonder if we could make it feel slightly better by applying a blur effect until it's fully loaded or even making it grayscale or something. Maybe it's a dumb idea, but I wonder if on worse connections that it'll be slow and they'll think we're loading in a really bad resolution then it suddenly swaps to the hires one. Curious what @Expensify/design thinks

bernhardoj · 2026-07-30T05:11:58Z

but it looks blurry then it loads in the unpixelated one is that correct

Yes, the image switching is actually an existing behavior. But in this PR, we switch from the low-res to the full-res. In prod, we switch from low-res to a higher one, but still blurry. Another new behavior in this PR is that no image is shown until the navigation transition is done.

dannymcclain · 2026-07-30T13:03:46Z

Yeah I'm not sure... For some of my receipts it took many seconds to swap to the higher res version, so it looked like the receipt was just blurry. And it seems like the height of the receipt preview area changes once the higher res version loads in? I wonder if it would be better to just spinner the whole thing until we can load the good version? It's not awful by any means, but it doesn't feel super great to me.

But also if this is essentially an upgrade of current behavior I guess we can proceed and keep trying to make it better.

mountiny · 2026-07-30T14:36:43Z

I think the delay is sort of inevitable as if the high resolution receipt is large, then its just taking a while to download couple megabytes and hence the delay. Only thing we could do is to show some loading feedback instead of just a blury larger low res image until the larger res loads

dannymcclain · 2026-07-30T14:58:32Z

Only thing we could do is to show some loading feedback instead of just a blury larger low res image until the larger res loads

Yeah that could definitely help. Even if it's a little unobtrusive thing that still let's you see the low res image in the background (so not totally blocking, but just gives you some affordance)

dubielzyk-expensify · 2026-07-31T00:29:51Z

Yeah, that's kinda what I was getting at. I'm aware the delay is by design, but I think the transition and general "waiting state" can be better. Do we have a way to actually understand when the new image is loaded in? If so, I wonder if we could dim the receipt with a spinner on top and then un-dim with the high resolutiojn receipt

bernhardoj · 2026-07-31T07:17:25Z

Do we have a way to actually understand when the new image is loaded in? If so, I wonder if we could dim the receipt with a spinner on top and then un-dim with the high resolutiojn receipt

Yes, we do. We actually already have a loading, but it's only shown after 200ms and if the thumbnail (the lower res) is still loading.

App/src/components/ImageWithLoading.tsx

Lines 138 to 143 in 1c596a1

    
           {isLoading && (!previewUri || isThumbnailLoading) && !isImageCached && !isOffline && ( 
        
               <LoadingIndicator 
        
                   iconSize={loadingIconSize} 
        
                   style={[styles.opacity1, styles.bgTransparent, loadingIndicatorStyles]} 
        
               /> 
        
           )}

We can simplify it and shows whenever the higher-res image is loading.

Here is how it looks (with the dim):

web.mp4

dannymcclain · 2026-07-31T13:04:24Z

Here is how it looks (with the dim):

The last few giant ones in your video still seem a bit weird*, but the first few with normal images actually felt pretty good to me.

*Why is the receipt preview area so massive? I thought it would only ever be as tall as the viewport available. Also I didn't see the spinner on those—is that just because it's out of view because the preview area is so massive?

Does seem like this could be a good solution though because it at least sets users expectations a bit better than just a blurry image.

bernhardoj · 2026-07-31T13:50:35Z

*Why is the receipt preview area so massive? I thought it would only ever be as tall as the viewport available.

This is an existing behavior. Maybe it was intentionally designed like that?

Also I didn't see the spinner on those—is that just because it's out of view because the preview area is so massive?

Yes, it's at the center of the image and since the image is really long, we need to scroll to the middle of the image to see it.

dannymcclain · 2026-07-31T14:05:47Z

*Why is the receipt preview area so massive? I thought it would only ever be as tall as the viewport available.

This is an existing behavior. Maybe it was intentionally designed like that?

This doesn't sound right to me. @Expensify/design what do y'all think? (Even so, this sounds like a separate issue from the one we're focusing on here.)

shawnborton · 2026-08-01T13:58:54Z

Hmm I think we did design it that way at one point (to cap the max-height) but then we got some weirdness with how to display the receipt in terms of using something similar to background: cover, etc. I guess the reality is that most receipts are pretty standard size and we don't run into this often. I'd be down to do nothing here or follow up and do something with these edge cases if you feel strongly!

Everything else seems to be looking nice to me though.

dubielzyk-expensify · 2026-08-03T01:48:30Z

I'd be down to do nothing here or follow up and do something with these edge cases if you feel strongly!

No strong feelings. Fine with following up. Might wanna do some prototyping for this and have clearer instructions 👍

bernhardoj · 2026-08-03T10:22:04Z

Cool. @mountiny, so should we go with that approach?

dannymcclain · 2026-08-04T13:03:42Z

No strong feelings here! Happy to proceed.

bernhardoj · 2026-08-06T02:12:17Z

@mountiny cool, looks like everyone is happy to proceed with the approach. Should I continue this PR and let a C+ review this or let Melvin create the PR and I review it?

mountiny · 2026-08-06T20:04:08Z

yeah if the design team is happy with this approach lets do it

bernhardoj · 2026-08-07T09:04:29Z

So this receipt image component is being used in several places, for example, here, in the report preview

or when viewing the expense on a small screen.

Both usages pass shouldUseThumbnailImage as true to the component. Do we also want to use the original image there or keep using the thumbnail when shouldUseThumbnailImage is true?

shawnborton · 2026-08-07T15:07:59Z

Probably fine to keep using the thumbnail versions?

mountiny · 2026-08-09T18:20:10Z

@MelvinBot @codex review

@thesahindia can you review this PR on Monday or is your plate full? thanks!

github-actions · 2026-08-09T18:22:07Z

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 63354a8585

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-08-09T18:25:36Z

            shouldUseThumbnailImage: shouldUseThumbnailImage ?? true,

-            source: thumbnailSource,
+            source: shouldUseThumbnailImage !== false ? thumbnailSource : originalImageSource,


Keep remote PDFs off the image loader

When the wide receipt panel passes shouldUseThumbnailImage={false}, this now sends originalImageSource even for remote PDF receipts. ReceiptImage then routes that .pdf URL into DeferredImageWithLoading/ImageWithLoading, which is the image pipeline, while the existing receipt URI helper intentionally provides a generated .jpg.1024.jpg thumbnail for PDFs and PDF rendering is handled by separate PDF components. On tablet/native or any no-hover context where the web-only PDF overlay is not mounted, opening a remote PDF receipt in the full-height receipt panel drops the JPG preview and leaves the receipt blank after the image load fails; keep the thumbnail source for PDFs or render a PDF component instead.

Useful? React with 👍 / 👎.

thesahindia · 2026-08-10T10:01:11Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

Screen.Recording.2026-08-11.at.2.00.33.AM.mov

iOS: HybridApp

iOS: mWeb Safari

Screen.Recording.2026-08-11.at.2.43.30.AM.mov

MacOS: Chrome / Safari

Screen.Recording.2026-08-11.at.12.51.59.AM.mov

joekaufmanexpensify

Good for product

thesahindia

Works well!

mountiny

Thank you for pushing this ahead ❤️

OSBotify · 2026-08-11T19:58:58Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-08-11T20:08:45Z

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

github-actions · 2026-08-11T20:16:22Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #97313.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-5e89148d49f-0e2bf42-1a91278386410ab24460a79cb70a771122afafd2/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-5e89148-0e2bf42-66f34cc8a3b806b11caf1605c186aa5b90fb44df/index.html

Web 🕸️
https://97313.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-08-12T18:39:27Z

🚀 Deployed to staging by https://github.com/mountiny in version: 9.4.53-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

MelvinBot · 2026-08-12T18:43:02Z

🤖 I reviewed the changes in this PR and no help site changes are required under docs/articles.

Why: This PR is an internal image-rendering improvement — it defers image loading during screen transitions (new DeferredImageWithLoading wrapper) and serves the original higher-resolution image for non-PDF receipts so hover-to-zoom is sharper. It introduces no new user-facing feature, setting, tab, button, or workflow. The behavior it improves (receipt preview loading and zoom quality) isn't documented in the help site — a search of docs/articles for hover, zoom, receipt image, image quality, and resolution returned no matching content, so there's nothing to update.

Since there are no required doc updates, I did not create a draft help site PR. @bernhardoj, if you believe a specific help article should be updated to reflect this change, let me know which one and I'll draft it.

jponikarchuk · 2026-08-13T10:50:55Z

This PR failing because of the issue #98566
This issue is reproducible in: Android app

jponikarchuk · 2026-08-13T13:23:45Z

Deploy Blocker #98587 was identified to be related to this PR.

OSBotify · 2026-08-14T20:16:07Z

🚀 Deployed to production by https://github.com/roryabraham in version: 9.4.53-10 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

Android

bernhardoj added 2 commits July 29, 2026 16:16

defer image loading until navigation transition ended

cc95429

use the original image source

305bd90

melvin-bot Bot assigned bernhardoj Jul 29, 2026

bernhardoj mentioned this pull request Jul 29, 2026

[Due for payment 2026-08-21] [$250] Improve hover-to-zoom preview quality for non-PDF (image) receipts #96999

Open

This comment has been minimized.

Sign in to view

bernhardoj added 4 commits August 7, 2026 14:54

Merge branch 'main' into feat/deferred-image-loading

ddddb3b

only use original image when shouldUseThumbnailImage is false

4322983

lint

23a7322

dim the thumbnail and always show loading when it's loading

8842980

Merge branch 'main' into feat/deferred-image-loading

5c1b53e

mountiny self-requested a review August 9, 2026 18:19

chatgpt-codex-connector Bot reviewed Aug 9, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

keep using thumbnail for pdf

511b90a

joekaufmanexpensify approved these changes Aug 10, 2026

View reviewed changes

thesahindia approved these changes Aug 11, 2026

View reviewed changes

quinthar added the #quality label Aug 11, 2026

mountiny approved these changes Aug 11, 2026

View reviewed changes

mountiny merged commit 5e89148 into Expensify:main Aug 11, 2026
38 of 41 checks passed

MelvinBot mentioned this pull request Aug 11, 2026

Report - Map disappears everytime user goes offline after changing expense rate. #98364

Open

7 tasks

OSBotify mentioned this pull request Aug 12, 2026

Deploy Checklist: New Expensify 2026-08-12 #98463

Closed

MelvinBot mentioned this pull request Aug 13, 2026

[Due for payment 2026-08-21] Spend - Receipt takes time to load after switching between tabs #98559

Closed

7 tasks

applause-bot Bot mentioned this pull request Aug 13, 2026

[Due for payment 2026-08-21] Scan - Blank placeholder is shown briefly after uploading receipt #98561

Closed

7 tasks

rinej mentioned this pull request Aug 13, 2026

[Due for payment 2026-08-21] [$250] Workflows - Approval Workflow lags and UI breaks after navigating back #94758

Open

7 tasks

applause-bot Bot mentioned this pull request Aug 13, 2026

97313 - Android - Receipt - Large receipt image stays lower-res #98566

Closed

7 tasks

applause-bot Bot mentioned this pull request Aug 13, 2026

[Due for payment 2026-08-21] Expense - Per diem expense receipt loads infinitely after reset app #98587

Open

7 tasks

applause-bot Bot mentioned this pull request Aug 13, 2026

[Due for payment 2026-08-25] Expense - Blank preview is shown after adding receipt, receipt reloads when reopen expense #98616

Open

7 tasks

mkhutornyi mentioned this pull request Aug 14, 2026

[CP Staging] fix Expense - Per diem expense receipt loads infinitely after reset app #98668

Merged

43 tasks

neerajbachani mentioned this pull request Aug 15, 2026

Add GitHub issue proposal for #98587 neerajbachani/App#8

Closed

Uh oh!

Conversation

bernhardoj commented Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

codecov Bot commented Jul 29, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

github-actions Bot commented Jul 29, 2026

Uh oh!

This comment has been minimized.

dubielzyk-expensify commented Jul 29, 2026

Uh oh!

bernhardoj commented Jul 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dannymcclain commented Jul 30, 2026

Uh oh!

mountiny commented Jul 30, 2026

Uh oh!

dannymcclain commented Jul 30, 2026

Uh oh!

dubielzyk-expensify commented Jul 31, 2026

Uh oh!

bernhardoj commented Jul 31, 2026

Uh oh!

dannymcclain commented Jul 31, 2026

Uh oh!

bernhardoj commented Jul 31, 2026

Uh oh!

dannymcclain commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shawnborton commented Aug 1, 2026

Uh oh!

dubielzyk-expensify commented Aug 3, 2026

Uh oh!

bernhardoj commented Aug 3, 2026

Uh oh!

dannymcclain commented Aug 4, 2026

Uh oh!

bernhardoj commented Aug 6, 2026

Uh oh!

mountiny commented Aug 6, 2026

Uh oh!

bernhardoj commented Aug 7, 2026

Uh oh!

shawnborton commented Aug 7, 2026

Uh oh!

mountiny commented Aug 9, 2026

Uh oh!

github-actions Bot commented Aug 9, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Aug 9, 2026

Choose a reason for hiding this comment

Uh oh!

bernhardoj Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

thesahindia commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

joekaufmanexpensify left a comment

Choose a reason for hiding this comment

Uh oh!

bernhardoj commented Jul 29, 2026 •

edited

Loading

codecov Bot commented Jul 29, 2026 •

edited by github-actions Bot

Loading

bernhardoj commented Jul 30, 2026 •

edited

Loading

dannymcclain commented Jul 31, 2026 •

edited

Loading

thesahindia commented Aug 10, 2026 •

edited

Loading