[Bug]: Empty sandboxed iframes throw "Blocked script execution" errors in Playwright

[krokben]

Version

1.48.2

Steps to reproduce

Example steps:

1. Clone my repo at https://github.com/krokben/sandboxed-iframe
2. npm install
3. npm run start
4. npm run test
5. Check for error: Blocked script execution in 'about:blank' because the document's frame is sandboxed and the 'allow-scripts' permission is not set. in the devtools console.

Expected behavior

For it to not throw an error when my website includes an injected iframe with an empty sandbox attribute.

Actual behavior

My page injects an iframe with an empty sandbox attribute. Running this page in the browser throws no error, but in playwright it throws this error:

Blocked script execution in 'about:blank' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Additional context

It looks like Playwright tries to run some scripts in all the iframes on the page, which probably leads to this issue. The behavior is then different from what one would expect when just visiting the page in the browser.

I would consider this a bug, but is there maybe some setting I can change in Playwright so that this doesn't happen?

My actual website relies on a third-party plugin that injects these sandboxed iframes, so i cannot influence what their code and add allow-scripts to the sandbox, for example.

Environment

System:
OS: macOS 14.7
CPU: (8) arm64 Apple M1
Memory: 81.13 MB / 8.00 GB
Binaries:
Node: 20.15.0 - ~/.nvm/versions/node/v20.15.0/bin/node
Yarn: 4.1.1 - ~/.nvm/versions/node/v20.15.0/bin/yarn
npm: 10.7.0 - ~/.nvm/versions/node/v20.15.0/bin/npm
pnpm: 9.12.3 - ~/.nvm/versions/node/v20.15.0/bin/pnpm
bun: 1.0.29 - ~/.bun/bin/bun
IDEs:
VSCode: 1.94.2 - /usr/local/bin/code
Languages:
Bash: 3.2.57 - /bin/bash
npmPackages:
@playwright/test: ^1.48.2 => 1.48.2

[Skn0tt]

Hey there, hope you're having a good day despite the fall-grey sky in Berlin!

I've taken a look at your repo and can also see the error, but Playwright's still working just fine it seems. I've modified your repo a bit to make it test something inside the iframe, and it's passing just fine:

diff --git a/tests/test.spec.ts b/tests/test.spec.ts
index bbd8866..5a5551d 100644
--- a/tests/test.spec.ts
+++ b/tests/test.spec.ts
@@ -6,6 +6,5 @@ test("sandboxed iframe", async ({ browser }) => {
 
   await page.goto("http://localhost:3000");
 
-  await page.locator("button").click();
-  await page.pause();
+  await expect(page.frameLocator('iframe').locator('button')).toBeAttached();
 });
diff --git a/website/index.html b/website/index.html
index 0f94277..8f760bd 100644
--- a/website/index.html
+++ b/website/index.html
@@ -10,9 +10,8 @@
       iframe.name = "frameId";
       iframe.style.display = "none";
       iframe.sandbox = "";
+      iframe.src = 'data:text/html,<button>click me</button>'
       window.document.body.appendChild(iframe);
     </script>
-
-    <button></button>
   </body>
 </html>

My understanding is that you're mostly worried about the error in the console. I think it's safe to ignore the error, as long as Playwright's still functioning fine. So does this impact your workflow in any way besides the error message?

[krokben]

Hi Simon Knott (@Skn0tt), thanks for your quick response!

So basically, what I'm using in my real project is Google IMA SDK, which is automatically injecting two OMID (Open Measurement) iframes with empty sandbox attributes to determine the viewability of the video, and it doesn't render the video element in the iframe when running in Playwright Chromium. The only errors I get that are not present when visiting the website normally, are these block script execution errors. So my suspicion is that the viewability scripts get blocked by Playwright somehow.

[Skn0tt]

I see, that makes sense. Could you extend your repro so that it incorporates these OMID iframes, and formulate new expected behaviour / actual behaviour? We can't investigate without a proper repro.

[krokben]

Simon Knott (@Skn0tt) Ok, I've replaced the website folder in the repo with this example project from Google IMA SDK: https://github.com/googleads/googleads-ima-html5/tree/main/simple and luckily, I get the same error when running a Chromium test with this example project as I do with my real project. Please have a look.

[Skn0tt]

Thanks, that's super helpful! Some observations:

1. the error message is indeed caused by Playwright trying to inject a script into the sandboxed iframe. i'm not sure if it fails at doing that and that's why we see the error, or if it succeeds but the browser incorrectly prints the error. that needs further investigation.
2. the mentioned script is used by the debugging functionality behind page.pause(). If you remove the page.pause call, the error goes away! It's like stagefright, the bug only appears when Playwright is being watched. You can check this yourself by adding page.on("console", msg => console.log(msg.text())) and running with and without page.pause().

I'll see if we should add some special behaviour to prevent our code from injecting into sandboxed frames. In the meantime, I think you should be fine ignoring the error. Debugging the sandboxed frame in page.pause() might not work as expected, but my understanding is that this doesn't cause any harm for you.

[krokben]

Simon Knott (@Skn0tt) Thanks, that clears things up a bit. I was down the rabbit hole of the sandboxed iframe error, when in fact my problem is that it blocks the loading of the video url. I have updated my test, and as you can see, it does actually change the source of the video element for a split-second, but then this error is printed to the console:

{
    "message": "",
    "stack": "Error\n    at new LQ (https://imasdk.googleapis.com/js/sdkloader/ima3.js:666:580)\n    at CR (https://imasdk.googleapis.com/js/sdkloader/ima3.js:695:208)\n    at Z.Db (https://imasdk.googleapis.com/js/sdkloader/ima3.js:690:99)\n    at qw (https://imasdk.googleapis.com/js/sdkloader/ima3.js:321:195)\n    at m.dispatchEvent (https://imasdk.googleapis.com/js/sdkloader/ima3.js:319:365)\n    at iO.F (https://imasdk.googleapis.com/js/sdkloader/ima3.js:573:172)\n    at mw (https://imasdk.googleapis.com/js/sdkloader/ima3.js:318:159)\n    at b (https://imasdk.googleapis.com/js/sdkloader/ima3.js:316:297)",
    "data": {
        "type": "adPlayError",
        "errorCode": 400,
        "errorMessage": "There was an error playing the video ad.",
        "innerError": "Error: There was an error playing the video ad."
    }
}

So as you can see, I still cannot test that the video is playing after pressing the play button, like I do in my test now, by checking await expect(video).toHaveJSProperty("paused", false);.

[Skn0tt]

Interesting! For my understanding, this issue is not related to Blocked script execution because your test code doesn't have page.pause(). Is that right?

[krokben]

Simon Knott (@Skn0tt) Exactly, it seems to rather be because Google IMA SDK is blocking the video if it's shown inside of Playwright. Like I said, the src attribute is set for a split second, but then it is removed again. And even the poster image of the video before clicking the play button is never displayed either.

[Skn0tt]

Hate to bring the bad news, but I think this is a Google IMA SDK issue then. If software actively prevents automation (which makes sense for Adtech!), there's nothing Playwright can do about it.

[krokben]

Simon Knott (@Skn0tt) I was afraid that would be the case. I must say though, that they don't block TestCafe, which is what I've been using until now when I'm considering switching to Playwright. But this is a bit of a dealbreaker, so unless there's a way to fix it from Playwright's side, or having Google help me with this issue, I may have to stick with TestCafe for now. But thanks for looking into it!

[bengotow]

Hey folks, just wanted to say thank you for the detailed debugging here! As of Chrome 129 or 130, sandboxed iFrames in my Electron app have also been generating this "Blocked script execution" warning. I was banging my head against the wall trying to figure out the source of the error to make sure it wasn't something important, and this thread made me realize that it only happens when the Chrome DevTools are open! In my case, it seems to be triggered by mutation to the iFrame's size while the devtools are open, but I feel it's safe to ignore now.

Thanks, happy new year!