chrome-extensions-samples
chrome-extensions-samples copied to clipboard
chrome.scripting.executeScript allFrames doesn't resolve on CSP-restrictive pages.
Describe the bug
chrome.scripting.executeScript
callback is never called (if using promises, the promise never resolves) when the page in which it's executed contains iframe with certain CSP headers that seem restrictive / safer.
To Reproduce
// background.js
chrome.action.onClicked.addListener((tab) => {
console.log('click');
chrome.scripting.executeScript(
{
target: {
tabId: tab.id,
allFrames: true,
},
'func': function() {
return document.activeElement;
},
'args': [],
},
(...args) => {console.log('callback', args)});
});
// manifest.json
{
"name": "Test executeScript",
"description": "",
"version": "0.0.1",
"manifest_version": 3,
"permissions": [
"scripting"
],
"background": {
"service_worker": "bg.js"
},
"action": {},
"minimum_chrome_version": "93.0.0.0",
}
And then click the extension icon on a site like https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
Expected behavior The Promise should throw or the callback should be called.
** Notes** I'm suspicious of Content Security Policy but I did not try using Charles (or similar proxy) to override header by header to know which one is messing up the extension. This may even be a bug using MV2, Chrome Input Tools also doesn't work on the Mozilla site.
Observe the error in ServiceWorker
context
Unchecked runtime.lastError: Cannot access contents of the page. Extension manifest must request permission to access the respective host.
Add to manifest.json
"host_permissions": ["https://developer.mozilla.org/"]
Since DOM element is not observable in ServiceWorker
context, adjust func
and callback to
chrome.scripting.executeScript(
{
target: {
tabId: tab.id,
allFrames: true,
},
'func': function() {
return document.activeElement.tagName;
},
'args': [],
},
(args) => {console.log('callback', args[0].result)});
I added host_permissions :///* and the same behavior happens. Do you have a repo or gist with an extension working like this? Or does specifying specifically mozilla's domain work different than the wildcard?
On Sun, May 22, 2022, 12:39 PM guest271314 @.***> wrote:
Observe the error in ServiceWorker context
Unchecked runtime.lastError: Cannot access contents of the page. Extension manifest must request permission to access the respective host.
Add to manifest.json
"host_permissions": ["https://developer.mozilla.org/"]
Since DOM element is not observable in ServiceWorker context, adjust func and callback to
chrome.scripting.executeScript( { target: { tabId: tab.id, allFrames: true, }, 'func': function() { return document.activeElement.tagName; }, 'args': [], }, (args) => {console.log('callback', args[0].result)});
— Reply to this email directly, view it on GitHub https://github.com/GoogleChrome/chrome-extensions-samples/issues/715#issuecomment-1133931921, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACY4ANWIZZE3GHQ6KCSFYTVLJPLFANCNFSM5WG62C6A . You are receiving this because you authored the thread.Message ID: @.***>
I tested on Chromium 104.0.5077.0 (Developer Build) (64-bit). You can substitute "<all_urls>"
as wild card equivalent
execute_script_test.zip.
Technically, "optional_permissions"
https://developer.chrome.com/docs/extensions/reference/permissions/#step-3-request-optional-permissions could be used.
What is the use case?
What are you trying to ultimately achieve?
I added host_permissions :///*
"host_permissions": ["*://*/"]
achieves the expected result.
I am building a keyboard (IME is only available on Chrome OS) so I need it to work on any inputable on any site. I know inputable can be set to context menu, but for accessibility I need to support at least two ways of opening the extension (shortcut or clicking the action)
I will try your example out. Thanks!!!
On Sun, May 22, 2022, 3:35 PM guest271314 @.***> wrote:
I added host_permissions :///*
"host_permissions": [":///"]
achieves the expected result.
— Reply to this email directly, view it on GitHub https://github.com/GoogleChrome/chrome-extensions-samples/issues/715#issuecomment-1133959355, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACY4AOZQTCSVPEF3XIXIUDVLKEBHANCNFSM5WG62C6A . You are receiving this because you authored the thread.Message ID: @.***>
@guest271314 I tested your zip, the "callback" log is never logged. I'm on Chrome version 101.0.4951.64... so I'm guessing it was fixed at some point between 101 and 104. I'll keep this bug open until 104 is stable
Should work on 101. I've been using that pattern for some time. You can download Chromium dev channel from https://download-chromium.appspot.com/ to test.
the "callback" log is never logged.
How do you know the callback is not fired? Are you checking for the callback to be fired in ServiceWorker
context? The callback does not propagate to the target Web page.
Yes, on the service worker context, the "click" is logged (before executeScript) and the callback line is never reached.
On Mon, May 23, 2022 at 6:14 PM guest271314 @.***> wrote:
the "callback" log is never logged.
How do you know the callback is not fired? Are you checking for the callback to be fired in ServiceWorker context? The callback does not propagate to the target Web page.
— Reply to this email directly, view it on GitHub https://github.com/GoogleChrome/chrome-extensions-samples/issues/715#issuecomment-1135189064, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACY4APMFX573AKQPIIFVLLVLP7LFANCNFSM5WG62C6A . You are receiving this because you authored the thread.Message ID: @.***>
-- Tomás Roggero https://tomasroggero.com
Did you download and test with Chromium Dev channel? To verify the issue is with the Chrome/Chromium version you are running, and not something else?