Chat - PDF preview is not displayed.

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open chat with other user
2. Click in + icon and select "Add attachment"
3. Select any PDF file and click in Open,

Expected Result:

A preview of the PDF is displayed before uploading to the conversation.

Actual Result:

Failed to load PDF file message occurs.

Workaround:

unknown

Platform:

Where is this issue occurring?

• Web
• mWeb

Version Number: 1.2.41-1
Reproducible in staging?: y
Reproducible in production?: n
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Bug5866652_13654_Web.mp4

Expensify/Expensify Issue URL:
Issue reported by: Applasue internal team
Slack conversation:

View all open jobs on GitHub

[OSBotify]

👋 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:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[abekkala]

@roryabraham Is there something from me (on the BZ team member side) that I need to do here?
I've never gotten a deploy blocker/hourly issue before

[roryabraham]

Whoops, sorry I missed this.

@roryabraham Is there something from me (on the BZ team member side) that I need to do here?

We'll need to complete the BugZero checklist when the issue is complete, but nothing else to do for now since DeployBlockers should not go external unless we consciously decide to make a special exception. By default DeployBlockers are internal.

[roryabraham]

Seems like this problem is related to the CSP:

[roryabraham]

This DeployBlocker was caused by #13546, but in this case there's really no way @marcaaron or anyone else could've detected this on dev without having impressive foresight, because the CloudFlare worker that defines our CSP cannot be tested on dev (yet).

Anyways, this should hopefully be pretty easy to sort out, but will not be possible to test locally.

[roryabraham]

Okay, actually this is a bit of a can of worms. According to this resource:

special URL schemes that refer to specific pieces of unique content, such as ... "blob:" ... are excluded from matching a policy of * and must be explicitly listed. Policy authors should note that the content of such URLs is often derived from a response body or execution in a Document context, which may be unsafe. ... allowing "blob:" or "filesystem:" URLs is equivalent to unsafe-eval.

I'm reading this to mean that adding worker-src: blob: to the CSP to fix this problem would be unsafe, and we might need to figure out a more clever way to allow this in the CSP.

[roryabraham]

I think technically the blob: represents raw binary data that exists on the user's machine in their browser's memory (i.e the PDF we want to view offline in this case). However, I don't know if it's safe to spawn a worker from that raw binary data or not. I haven't been able to find any clear guidance about this and I'm not sure what to do 😕

[marcaaron]

Just updating this with the convo from this thread. The blob: in question comes from our own source and not provided by the user. I think for a plan of action we should:

• Revert the problematic PR
• Start a discussion with Group IB / Infra / whoever
• Fix the CSP (if we agree with that solution)
• Re-open the original PR

[yuwenmemon]

Original PR is reverted, removing the deployblocker label

[abekkala]

I'm now ooo and there is one task for the BZ being:

We'll need to complete the BugZero checklist

Reassigning label

[roryabraham]

Closing this since the problem PR was reverted, discussion can continue in #12512