[Due for payment 2025-01-22] [$250] Mac/Safari - [AU] Attachment - "WebKitBlobResource error" console error when sending a PDF attachment

[IuliiaHerets]

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.0.79-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5386106&group_by=cases:section_id&group_id=292107&group_order=asc
Issue reported by: Applause Internal Team
Device used: macOS Sequoia 15.0 - Safari
App Component: Other

Action Performed:

1. Navigate to https://staging.new.expensify.com/ and open Safari Web Inspector
2. Log in with a new Gmail account
3. Open any 1:1 DM
4. Send any PDF attachment

Expected Result:

Console error shouldn't show.

Actual Result:

"WebKitBlobResource error" console error when sending a PDF attachment to a 1:1 DM.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6703307_1735366281759!Console.txt

Bug6703307_1735366281706.Screen_Recording_2024-12-27_At_22.03.00.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021876132827778405205
• Upwork Job ID: 1876132827778405205
• Last Price Increase: 2025-01-06
• Automatic offers:
• shubham1206agra | Contributor | 105616263

Issue Owner

Current Issue Owner: @RachCHopkins

[melvin-bot]

Triggered auto assignment to @RachCHopkins (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[kpadmanabhan]

Proposal

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

Uploading of attachment in 1:1 DM shows console error

What is the root cause of that problem?

Though on an initial look, this may point fingers at Safari unable to handle pdf blobs, it is not a Safari alone issue. As against what's tagged in the title of this bug, this occurs on other browsers as well.

As Blob URLs are temporary in memory references to data from browser memory, a GET call to this URL fails to get it, because the encryptedAuthToken is invalid.

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

If we make a call to the blob URL without the encryptedAuthToken, the call succeeds.

The attachment is added without encryptedAuthToken in
https://github.com/Expensify/App/blob/main/src/pages/home/report/ReportActionCompose/ReportActionCompose.tsx#L262
However a further call to get attachment is made using encryptedAuthToken, which results in display of error message in console.

Remove encryptedAuthToken parameter if reportAction is attachment without any comment.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N.A.

What alternative solutions did you explore? (Optional)

N.A.

[shubham1206agra]

Proposal

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

Attachment - "WebKitBlobResource error" console error when sending a PDF attachment

What is the root cause of that problem?

When we upload the PDF file, we store the file temporarily in Browser file blob storage. But when we try to fetch the file using source, we add the encryptedAuthToken here

App/src/components/AnchorForAttachmentsOnly/BaseAnchorForAttachmentsOnly.tsx

Line 26 in b7b5dda

const sourceURLWithAuth = addEncryptedAuthTokenToURL(source);

But we should not have added the authToken for temporary file in memory.

This causes the console error since the file could not be loaded.

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

Change source to use without encryptedAuthToken, and add isAuthTokenRequired={!!sourceID} to add the authToken when required.

App/src/components/AnchorForAttachmentsOnly/BaseAnchorForAttachmentsOnly.tsx

Line 61 in b7b5dda

source={sourceURLWithAuth}

To make the desired behavior, we also have to update the condition here

App/src/components/Attachments/AttachmentView/index.tsx

Line 178 in b7b5dda

if (!hasPDFFailedToLoad && (isSourcePDF || isFilePDF)) {

to stop rendering the pdf view when the file is being uploaded.

Use !isUploading && !hasPDFFailedToLoad && (isSourcePDF || isFilePDF)

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

NA

[RachCHopkins]

I think this is related to last week's fire. @IuliiaHerets can we please get a retest?

[IuliiaHerets]

@RachCHopkins Tester still can reproduce this issue in the latest build v9.0.80-1

Screen.Recording.2025-01-01.At.5.59.51.mp4

[melvin-bot]

@RachCHopkins Whoops! This issue is 2 days overdue. Let's get this updated quick!

[RachCHopkins]

I can't repro this at all.