Closed Bug 1724924 Opened 4 years ago Closed 7 months ago

Disallow displaying PDFs in sandboxed iframes

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

RESOLVED FIXED
134 Branch
Tracking Status
firefox134 --- fixed

People

(Reporter: d, Assigned: farre)

References

()

Details

(Keywords: parity-chrome, parity-safari, Whiteboard: [pdfjs-integration], [wptsync upstream])

Attachments

(1 file)

Changing components since this is a PDF Viewer bug.

Component: Plug-ins → PDF Viewer
Product: Core → Firefox
Whiteboard: [pdfjs-integration]

This is still an issue per
http://wpt.live/html/semantics/embedded-content/the-iframe-element/sandbox_004.htm

Our behavior here is sort of in the right direction - we don't actually display the PDF, but we do display the PDF-viewer-UI (without any PDF document inside of it). And we fail to display the fallback content, if fallback content is provided.

The pdf viewer shouldn't be involved in such case so I don't think it's a pdf.js bug but more likely a bug in DOM (Core & HTML ??).
If we don't have any fallback, do we want to display a download button or something like that (like for bug 1655525) ?
:dholbert, wdyt ?

Flags: needinfo?(dholbert)

(In reply to Calixte Denizet (:calixte) from comment #4)

The pdf viewer shouldn't be involved in such case so I don't think it's a pdf.js bug but more likely a bug in DOM (Core & HTML ??).

Agreed (DOM: Core&HTML or perhaps DOM: Security). --> Reclassifying.

If we don't have any fallback, do we want to display a download button or something like that (like for bug 1655525) ?

I'm not super familiar with sandboxed iframes, so I don't have a good intuition of whether that'd be worth doing (or worth not-doing).

FWIW Chrome doesn't seem to provide any fallback in this case, based on some local testing I just did (editing a local copy of the iframe in the WPT that I linked in comment 3, and viewing it through the WPT harness).

Component: PDF Viewer → DOM: Core & HTML
Flags: needinfo?(dholbert)
Product: Firefox → Core

farre, I vaguely recall that you worked on the object element at some point. Does this look to you like this would be easy to do?

Severity: -- → S3
Flags: needinfo?(afarre)
Priority: -- → P3

I'll take a look at it.

Flags: needinfo?(afarre)
Flags: needinfo?(afarre)
Assignee: nobody → afarre
Status: NEW → ASSIGNED

Given that my solution is correct, this turned out to be relatively simple. Unfortunately I haven't been able to confirm with spec how this is supposed to be achieved, since the spec change detailed in this bug has long since been re-written to something else.

Flags: needinfo?(afarre)
Pushed by afarre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7eaef5ce1448 Disallow displaying PDFs in sandboxed iframes. r=dom-core,sefeng
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/49142 for changes under testing/web-platform/tests
Whiteboard: [pdfjs-integration] → [pdfjs-integration], [wptsync upstream]
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 134 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: