Bug 290935
| Summary: | [SOUP] PDF preview does not work (blob not loaded due to CSP) | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | dev.xszelu |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro, neil |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | PC | ||
| OS: | Linux | ||
dev.xszelu
# Details of the platform
* Epiphany version: 48
* WebKitGTK version (from About Web -> Troubleshooting -> Debugging Information):
WebKitGTK 2.48.0
GStreamer 1.24.12
GTK 4.18.2
Libadwaita 1.7.0
Distributor: GNOME
* Distributor (Linux operating system, Flathub, Epiphany Tech Preview, etc.): Flatpak distributed through Flathub on Fedora 41
# Description of the issue
I use Gnome Web as PWA to access the Fastmail website / email service. They offer a preview of the attachments which works for images, and used to work for PDF - I cannot recall when it stopped working. Now when clicking on the PDF, preview is opened but the PDF does not load. Using Gnome Web to read PDFs continue to work.
After discussion with the support of Fastmail, they recommended that I open a bug report as this works with all other major browsers and seems related to how Web handles CSP for blob: "This seems a bug. That CSP is the content security policy of the HTML page. It looks like when you load a `blob:` URL within the page it's returning the same CSP the page has with the response, when it shouldn't be returning any CSP for this (and works in Safari, Firefox, and Chrome)."
This was initially reported there: https://gitlab.gnome.org/GNOME/epiphany/-/issues/2628
# Further details
Opening up the console, I'm seeing the following error messages when trying to load up a PDF file:
[Error] Unrecognized Content-Security-Policy directive 'manifest-src'.
[Error] Unrecognized Content-Security-Policy directive 'manifest-src'.
[Error] Refused to load blob:https://app.fastmail.com/uuid-of-the-resource because it does not appear in the frame-ancestors directive of the Content Security Policy.
Headers in the network tab when clicking on the resource:
### Summary
URL: blob:https://app.fastmail.com/uuid-of-the-resource
Status: 200 OK
Source: Network
### Request
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/60.5 Safari/605.1.15
### Response
Content-Length: 287441
Content-Security-Policy: default-src 'none'; connect-src 'self' blob: https://lookup.binlist.net https://api.pinpayments.com https://o73885.ingest.sentry.io/api/ https://fastmail.innocraft.cloud https://hcaptcha.com https://*.hcaptcha.com https://*.fastmail.com https://*.fastmailusercontent.com; img-src 'self' data: blob: https://user.fm https://*.fastmailusercontent.com; font-src 'self'; style-src 'self' 'unsafe-inline' https://hcaptcha.com https://*.hcaptcha.com; script-src 'self' https://hcaptcha.com https://*.hcaptcha.com 'sha256-t8juR3Hb+ug9vfYHONqL1b/qFVPGJU9o5ACeVU97YZQ=' 'sha256-gz1/DmrGiQg8Krh+rxYRowwlkZ1AEGi9G2ceZQ5SHR0=' 'sha256-iCXxsET7zlAWnFxvWhVmmUn/6n3hDwTJxu+JbcI93Uw='; child-src 'self'; worker-src 'self'; manifest-src 'self'; media-src blob: https://*.fastmailusercontent.com; object-src blob: https://*.fastmailusercontent.com; frame-src blob: https://hcaptcha.com https://*.hcaptcha.com https://*.fastmail.com https://*.fastmailusercontent.com; form-action 'self'; frame-ancestors 'none';
Content-Type: application/pdf
Referrer-Policy: same-origin
Security tab when clicking on the resource: "The resource was requested insecurely."
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Michael Catanzaro
Good news: I'm also a Fastmail customer, and I can reproduce.
Next step: I'll find time to test with 2.46 to see whether it broke due to a WebKit change rather than a Fastmail change. If it works in 2.46, then I will bisect it.
Michael Catanzaro
Notably the problem here is we have an HTML document embedded inside the parent HTML document. I didn't know that was possible. It looks like this:
<object data="blob:https://app.fastmail.com/uuid" type="application/pdf" class="v-Blob-native">
<html>
<head></head>
<body></body>
</html>
</object>
(I censored the UUID because I'm not sure whether that's sensitive or not.) The embedded document is empty due to the CSP failure.
neil
> broke due to a WebKit change rather than a Fastmail change.
Just to save you some time bisecting, we made a change at Fastmail to allow better caching control, so this is probably not due to a recent WebKit change. However, in doing so it seems we ran into this bug in Gnome. The way it now works is we download a blob of the PDF data, then do essentially:
```
const url = URL.createObjectURL(new File([blob], "filename.pdf", {type: "application/pdf"});
const obj = document.createElement('object');
obj.type = "application/pdf";
obj.data = url;
destination.appendChild(obj);
```
Each browser then has its own approach to rendering the PDF, but whatever Epiphany is doing it seems to be blocking itself with the CSP that should only be applying to the parent HTML page.
Michael Catanzaro
Hi there! So if this is specific to PDF, then it's surely a duplicate of bug #272590. I previously said in the Epiphany bug that this looked different, but evidently that was wrong.
WebKit's PDF implementation is completely different on macOS (which uses a proprietary Apple implementation) vs. Linux (which uses PDF.js, written by Apple for Apple but never actually used there) so it's not surprising that the bug is platform-specific. The PDF.js support is in bad shape....
*** This bug has been marked as a duplicate of bug 272590 ***