Closed fregante closed 10 months ago
The repro should look something like:
<html>
<body>
<!-- srcdoc or src, same issue-->
<iframe srcdoc="<p>Hello world!</p>" sandbox>
</body>
</html>
console.log('contentscript.js')
import('./secondary.js')
console.log('secondary.js')
{
"name": "sandbox iframe",
"version": "1.0.7",
"manifest_version": 2,
"description": "Demo extension",
"content_scripts": [
{
"matches": ["*://*/*"],
"js": ["contentscript.js"],
"all_frames": true,
"match_about_blank": true
}
]
}
Using
"webpack": "^5.89.0",
"webpack-target-webextension": "^1.1.0",
I'll investigate this next week, thanks for your report!
Thank you! By the way this is the actual error produced:
It seems that the modules are loaded, but they are not registered in the global chunk list, so after the import()
is completed, the chunk can't be found on that line.
Does the chunk loader inject script
tags in order to work? Even after using import()
to load them? Because that's how the content script might end up running in the "unsafe world" and be blocked.
@fregante according to the error message, the execution failed because the "document's frame is sandboxed and the 'allow-scripts' permission is not set."
did you try <iframe sandbox="allow-scripts" ...
?
The point is that the script is running, regardless of the sandbox, because that error comes from webpack.
The main chunk runs, the imports don't.
Imports should run too, as shown in the import()
example, without altering/losing the sandbox.
hello, I found it is a Chrome bug. See https://bugs.chromium.org/p/chromium/issues/detail?id=816121 and please state your use case to let it fixed.
I'll try to make a workaround.
@fregante plz try this https://github.com/awesome-webextension/webpack-target-webextension/pull/42
I found a way via fetch
:
async function init() {
console.log('Hello from content script')
const inner = await fetch(chrome.runtime.getURL('./inner.js'))
const innerText = await res.text()
import(`data:text/javascript;charset=utf-8,${encodeURIComponent(innerText)}`).then(console.log)
}
init()
// inner.js
export const foo = 123;
console.log('Hello from inner script')
…but that's gonna break sourcemaps so it's not a great solution to this. Maybe this already works:
https://github.com/awesome-webextension/webpack-target-webextension#optionsbackground
hello, I found it is a Chrome bug. See https://bugs.chromium.org/p/chromium/issues/detail?id=816121 and please state your use case to let it fixed.
I don’t think that's quite the same issue, although it's certainly related. The issue mentions <iframe sandbox src="chrome-extension://">
rather than content scripts and import()
specifically.
It's a different context entirely: "main world on extension page" vs "isolated world on web page".
In our case, scripts do run, but import()
fails. It's a dejavu to the times when import()
did not work in content scripts because the script was being interpreted in the wrong context. I think the sandbox
is escaping/breaking the fix that was implemented at that time.
Related discussions:
hi, 1.1.1 has been released @fregante
https://github.com/awesome-webextension/webpack-target-webextension/blob/master/CHANGELOG.md#111
I'm still looking into it, but it seems that the first chunk runs correctly, but then anything
import()
'd fails with this error:It looks like
import
works fine though, I can run this in the console for that frame: