1941725 - iframe.src no longer loads PDFs into an iframe, starting with 134.0. Instead, the file is downloaded (and opened in a new tab, depending on browser settings)

Status: RESOLVED FIXED

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

Description

[Yuliia]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Use the following JavaScript code to dynamically create an iframe and set its src to a PDF file URL:
var frame = document.createElement("iframe");
frame.id = id;
frame.style.display = 'none';
frame.style.height = '100%';
frame.style.width = '100%';
frame.src = fileUrl;

Ensure the server sends the following HTTP headers for PDF files:
Content-Disposition: inline; filename="example.pdf"
Content-Type: application/pdf

Use Firefox 134.0 or later.

Actual results:

The PDF file is downloaded (and opened in a new tab if it's set in browser settings to open PDF files)

Expected results:

The PDF file should open in the iframe in the same tab

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Francesco Lodolo [:flod]]

(please move if there's a better component)

@Yuliia
Any chance you could try running mozregression to help to identify the issue? You good use --good 133 --bad 134 if it was working in 133, and you have a working example available.
https://mozilla.github.io/mozregression/quickstart.html

Comment 3

[Yuliia]

(In reply to Francesco Lodolo [:flod] from comment #2)

(please move if there's a better component)

@Yuliia
Any chance you could try running mozregression to help to identify the issue? You good use --good 133 --bad 134 if it was working in 133, and you have a working example available.
https://mozilla.github.io/mozregression/quickstart.html

According to mozregression, the last good build is 2024-11-12, and the first bad build is 2024-11-13. When trying to test further to pinpoint the issue, I encounter the error "Process exited with code 3221225622".

I also attempted to manually check the builds, and the last good build I found is 2024-11-13-09-48-33-mozilla-central/ and the first bad one is 2024-11-13-21-52-56-mozilla-central/

Comment 4

[Francesco Lodolo [:flod]]

I think that should map to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=723946b9a47990aa6253585366bb18863de4df33&tochange=108d038388ff70457b2ec3e74241f7769c281d34

I think that might be bug 1724924? According to the bug, Chrome's behavior should be the same as Firefox 134+?

Comment 5

[Andreas Farre [:farre]]

Attachment: Bug 1941725 - Add wpt test for dynamic iframe pdf viewer. r=#dom-core

Comment 6

[Andreas Farre [:farre]]

I couldn't reproduce this, so I threw together a wpt test. It's running on try, we'll see how that goes. Until then I think I need to know more.

Yuliia, do you have any particular settings or extensions active related to PDFs? Also, the iframe you're creating, I think I need to know about the enclosing iframe. Does that have a sandbox active?

The conundrum is that the test testing/web-platform/tests/html/semantics/embedded-content/the-iframe-element/iframe_sandbox_iframe_pdf_viewer.html should fail catastrophically if PDFs didn't load in iframes, since that test is a mismatch test, i.e it only succeeds if the ref is different, but if both fail to load pdf they're exactly the same and should in that case fail. This leads me to suspect that a sandbox is there somehow. If bug 1724924 is the regressor, I mean.

Comment 7

[Yuliia]

(In reply to Andreas Farre [:farre] from comment #6)

I couldn't reproduce this, so I threw together a wpt test. It's running on try, we'll see how that goes. Until then I think I need to know more.

Yuliia, do you have any particular settings or extensions active related to PDFs? Also, the iframe you're creating, I think I need to know about the enclosing iframe. Does that have a sandbox active?

The conundrum is that the test testing/web-platform/tests/html/semantics/embedded-content/the-iframe-element/iframe_sandbox_iframe_pdf_viewer.html should fail catastrophically if PDFs didn't load in iframes, since that test is a mismatch test, i.e it only succeeds if the ref is different, but if both fail to load pdf they're exactly the same and should in that case fail. This leads me to suspect that a sandbox is there somehow. If bug 1724924 is the regressor, I mean.

I think I misunderstood the issue earlier, sorry for that. Here’s an example that demonstrates the problem:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Dynamic iframe Example</title>
</head>
<body>
<h1>Click the button to add an iframe dynamically</h1>
<button onclick="addIframe()">Add PDF</button>

<div id="iframeContainer"></div>

<script>
    function addIframe() {
        var id = "iframe_print";
        var onFocusFunc = function () { removeFrames(); };

        function removeFrames(error) {
            var ifr = document.getElementById(id);
            if (ifr) {
                window.removeEventListener("focus", onFocusFunc);
                ifr.remove();
                if (error) {
                    console.log('on error');
                    return;
                }
                console.log('on success');
            }
        }

        var container = document.getElementById("iframeContainer");

        var frame = document.createElement("iframe");
        frame.id = id;
        frame.style.display = 'none';
        frame.style.height = '100%';
        frame.style.width = '100%';
        

        frame.sandbox = "allow-same-origin allow-popups allow-forms allow-popups-to-escape-sandbox allow-downloads allow-scripts allow-modals";

        window.addEventListener("focus", onFocusFunc);

        container.appendChild(frame);

        frame.onload = function () {
            var that = this;
            setTimeout(function () {
                try {
                    that.contentWindow.print();
                } catch (e) {
                    removeFrames(true);
                }
            }, 0);
        }

        frame.src = 'sample.pdf';
    }
</script>

</body>
</html>

(Place the HTML file and any sample.pdf in the same directory. Then, run the following commands to set up a local server
npm install http-server
npx http-server -p 3000)

that should demonstrate the problem I'm having on version 134:
expected result (as on 133) : pdf file is being opened in a printing dialog
actual result: file is downloaded (and opened in a new tab, depending on browser settings)

Comment 8

[Andreas Farre [:farre]]

Right, so then we can confirm that we're trying to open a pdf in an iframe with a sandbox. If we try this is chrome we can see that this get's blocked entirely, which is actually what we want in Firefox as well. So the fact that it opens in a tab instead of the iframe is the actual bug here.

Hsin-Yi, I'm not sure who to ask for some cycles to look at this. It's definitely an S3 at most.

Comment 9

[Yuliia]

(In reply to Andreas Farre [:farre] from comment #8)

Right, so then we can confirm that we're trying to open a pdf in an iframe with a sandbox. If we try this is chrome we can see that this get's blocked entirely, which is actually what we want in Firefox as well. So the fact that it opens in a tab instead of the iframe is the actual bug here.

Hsin-Yi, I'm not sure who to ask for some cycles to look at this. It's definitely an S3 at most.

Thank you for your response. To better understand the intended behavior, I’d like to clarify the following scenario:
if I dynamically create a sandboxed iframe (iframe1) and then dynamically create a non-sandboxed iframe (iframe2) inside iframe1, should iframe2 be allowed to open a PDF file?

Comment 10

[Andreas Farre [:farre]]

(In reply to Yuliia from comment #9)

(In reply to Andreas Farre [:farre] from comment #8)

Right, so then we can confirm that we're trying to open a pdf in an iframe with a sandbox. If we try this is chrome we can see that this get's blocked entirely, which is actually what we want in Firefox as well. So the fact that it opens in a tab instead of the iframe is the actual bug here.

Hsin-Yi, I'm not sure who to ask for some cycles to look at this. It's definitely an S3 at most.

Thank you for your response. To better understand the intended behavior, I’d like to clarify the following scenario:
if I dynamically create a sandboxed iframe (iframe1) and then dynamically create a non-sandboxed iframe (iframe2) inside iframe1, should iframe2 be allowed to open a PDF file?

No, sandbox properties a propagated.

Comment 11

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Andreas Farre [:farre] from comment #8)

Right, so then we can confirm that we're trying to open a pdf in an iframe with a sandbox. If we try this is chrome we can see that this get's blocked entirely, which is actually what we want in Firefox as well. So the fact that it opens in a tab instead of the iframe is the actual bug here.

Hsin-Yi, I'm not sure who to ask for some cycles to look at this. It's definitely an S3 at most.

Not having a quick thought of resource allocation due to S3 severity, still reviewing the team queue.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:farre, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 13

[Edgar Chen [:edgar] (PTO 2/2 ~ 2/6)]

( I’ll let Andreas take this one :) )

Comment 14

[Andreas Farre [:farre]]

Attachment: Bug 1941725 - Make blocking of PDFs in sandboxed containers stricter. r=smaug!

Comment 15

[Andreas Farre [:farre]]

Attachment: /home/farre/Pictures/Screenshots/chromeexternal.png

Chrome changes to this when changing default PDF behaviour to download only.

Comment 16

[Andreas Farre [:farre]]

Attachment: Bug 1941725 - Test iframe sandboxed PDFs. r=smaug!

PDFs in sandboxed iframes are blocked when handled internally,
regardless of sandbox flag.

If the sandbox flag is allow-downloads and the default action is to
not show the PDF inline, allow the action.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c5c045359ab9
Make blocking of PDFs in sandboxed containers stricter. r=smaug
https://hg.mozilla.org/integration/autoland/rev/e54cca11f05f
Test iframe sandboxed PDFs. r=smaug

Comment 18

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/c5c045359ab9
https://hg.mozilla.org/mozilla-central/rev/e54cca11f05f