Repository navigation
[$500] PDF receipt preview loads each time visiting 1:1 DM, report and transaction thread #37852
Description
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: 1.4.48-0
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:
Action Performed:
- Go to staging.new.expensify.com
- Go offline.
- Go to FAB > Request money > Scan.
- Select a PDF receipt.
- Select any participant and create the Scan request.
- in 1:1 DM, click on the scan preview.
- In IOU report, click on the scan preview.
- Click on the header subtitle to return to report and 1:1 DM.
Expected Result:
The PDF receipt preview will not load each time going back and forth between 1:1 DM, IOU report and transaction thread.
Actual Result:
The PDF receipt preview loads each time going back and forth between 1:1 DM, IOU report and transaction thread. Sometimes it shows blue "loading page" briefly when the receipt is rendering.
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- Android: Native
- Android: mWeb Chrome
- iOS: Native
- iOS: mWeb Safari
- MacOS: Chrome / Safari
- MacOS: Desktop
Screenshots/Videos
Add any screenshot/video evidence
Bug6404710_1709766997050.bandicam_2024-03-07_07-10-11-388.mp4
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~016df3671b30e63c80
- Upwork Job ID: 1806060107499225786
- Last Price Increase: 2024-07-24
Activity
github-actions commentedon Mar 6, 2024
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
melvin-bot commentedon Mar 6, 2024
Triggered auto assignment to @anmurali (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.melvin-bot commentedon Mar 6, 2024
Triggered auto assignment to @deetergp (
Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.kavimuru commentedon Mar 6, 2024
@anmurali FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.
127 remaining items
tsa321 commentedon Jul 21, 2024
@s77rt
for navigating back to main expense chat, you can switch to another chat and then return to the main expense chat; you will see the loading spinner.s77rt commentedon Jul 21, 2024
@tsa321 Going back to the IOU report via the "From" link does not cause the preview to reload, but doing so from the LHN reloads the preview. Can you explain why is that happening?
Screen.Recording.2024-07-21.at.5.58.13.PM.mov
tsa321 commentedon Jul 23, 2024
@s77rt, please wait. I will try to take a look.
s77rt commentedon Jul 23, 2024
Waiting on proposals...
tsa321 commentedon Jul 24, 2024
@s77rt The PDF also loads immediately when the user presses the browser's back button. When the user presses the link to the parent report in the report header, it functions similarly to going back (much like pressing the browser's back button). Perhaps the stack navigation/browser preserves the content of the previous screen/route, allowing the PDF to load immediately.
melvin-bot commentedon Jul 24, 2024
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
s77rt commentedon Jul 24, 2024
@tsa321 I don't think we really have a bug then. Opening a new report renders a new PDF Previewer and the loader is expected since the pdf is loaded at library level (unlike images where they are loaded at the browser level where caching is implemented). This can be a feature request but if we implement a caching mechanism it should be at
react-pdflevel and we should cache the pdf content and not its thumbnail.(Same note applies for mobile if the bug is reproducible there)
tsa321 commentedon Jul 24, 2024
@s77rt Actually, we can cache all pages of the PDF as images. Is this the expected result? Caching the PDF means converting it into images, correct? Also, the server returns the PDF thumbnail as images too. Why should we do this at the
react-pdflevel? We can do it in the app.s77rt commentedon Jul 24, 2024
@tsa321 Caching is to save the pdf data (bytes) for a given uri. If we use a known uri we'd use the cached data instead of fetching that uri contents again.
It's a feature for
react-pdfand not related to the app.For this case the feature is a low priority since the uri that the PDF Previewer will load always points to a local file
tsa321 commentedon Jul 24, 2024
@s77rt, the PDF file is already stored as a blob URI, meaning it's stored in memory as bytes.
I believe we may have different perspectives on PDF caching:
My understanding is that PDF rendering involves drawing various elements such as text, lines, shapes, rectangles, paths, vectors, and images specified in the PDF file onto a canvas. This process is managed by react-pdf or whichever PDF engine library is utilized (indicated by the loading spinner during rendering).
On the other hand, caching the PDF means storing the rendered result as an image, so that it doesn't need to be redrawn.
However, I agree that this issue is of very low priority. I'm okay with closing this issue. @deetergp, what are your thoughts on this issue? Thank you.
s77rt commentedon Jul 25, 2024
@deetergp Let's close this based on #37852 (comment)
deetergp commentedon Jul 25, 2024
Sounds like a plan @s77rt 👍