Inline script execution in content scripts manifest version 3

[Vinod Kumar]

Hi,

How to do inline script execution in manifest 3 chrome extension inside content scripts.

Following is the sample code how we are doing the inline script execution.

var script = doc.createElement('script');

script.setAttribute("type", "application/javascript");

script.textContent = "dynamic script content";

doc.documentElement.appendChild(script); // run the script

doc.documentElement.removeChild(script); // clean up

How to make the above code to work in manifest version 3 extension.

Regards,

Vinod.

[Oliver Dunk]

Hi Vinod,

We have deliberately tried to move away from this sort of thing in Manifest V3, since executing arbitrary code from text can be dangerous.

Assuming you already know the code you'd like to run, you can use the scripting API to execute a function or file: https://developer.chrome.com/docs/extensions/reference/scripting/#method-executeScript

The code you shared would work, but only for scripts running in the MAIN world and assuming it does not violate the CSP of the page you are injecting on: https://developer.chrome.com/docs/extensions/mv3/content_scripts/#:~:text=related%20frames.-,world,-ExecutionWorld

As a note, if you inject anything that comes from a remote source that would be a violation of our updated policies: https://developer.chrome.com/docs/webstore/program-policies/mv3-requirements/

I hope that helps.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/b0c01d7c-30a7-4b68-ad8d-25930a8c0adcn%40chromium.org.

[Vinod Kumar]

Thanks Oliver for a quick reply.

I need to execute the dynamic script inside content scripts. I guess chrome.scripting.executeScript API can be used only inside background scripts.

Regards,

Vinod.

[Oliver Dunk]

Hi Vinod,

It's only available on extension origins (so, extension pages and the service worker for example).

You could send a message from your content script to the background though - would that help?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Vinod Kumar]

Hi Oliver,

 I used the scripting API to run the inline scripts but it is asynchronous. There is a bug logged for this

https://bugs.chromium.org/p/chromium/issues/detail?id=1207006

[Oliver Dunk]

Hi Vinod,

Could you share some more about your use case?

There are a few situations where this is definitely useful, though it's worth noting there was never a 100% reliable way to do this in MV2.

In lots of other cases, there's an alternative that we might be able to figure out for you.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[wOxxOm]

>  though it's worth noting there was never a 100% reliable way to do this in MV2

You're wrong. It was working with 100% reliability in MV2 by setting the script element's textContent as shown in the original message.

[Oliver Dunk]

It was working with 100% reliability in MV2 by setting the script element's textContent as shown in the original message.

I think there are a few different cases being discussed here between the different messages. I agree that the above code would work in MV2, but it isn't really complete (it doesn't show how dynamic content is determined, which likely involves an asynchronous API call).

If we knew more about Vinod's use case it might be easier to reason about :)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Vinod Kumar]

Hi Oliver,

I posted a separate question for this use case. Please check the link.

https://groups.google.com/a/chromium.org/g/chromium-extensions/c/tfhOngVsDc0/m/ELgNP9J5AAAJ

Thanks for your reply.

[wOxxOm]

> but it isn't really complete (it doesn't show how dynamic content is determined, which likely involves an asynchronous API call).

Only true in this specific case, so you need to mention such constraints explicitly as there are also cases where the code is constructed in the content script without the need for any asynchronous calls e.g. to embed a secret key generated via Math.random(). There's no way to do it in ManifestV3 due to the absence of something like chrome.scripting.setData to pass a config to the content script. The closest thing is chrome.userScripts API, but it's a hammer that's too big and currently gated behind an inconvenient mechanism, also it won't help if the requirement is to communicate with the ISOLATED world safely i.e. via a random event name.

BTW, your team also needs to mention such constraints explicitly for their other largely incorrect claims like these:

• "the persistent script is bad for performance" is true when the extension runs relatively rarely - although most extensions are arguably like this, there are also vital exceptions where the opposite is true i.e. non-persistent script is bad for performance due to the state being too complex to rebuild or the script is just huge and takes a lot of time to compile/run.
  
  
• "background pages are bad for performance" is entirely false, the opposite is true as the page can be persistent or lazy to match the usage pattern of the extension, I guess whoever wrote this part didn't know that an event page is also a background page.
  
  
• "webRequestBlocking is bad for performance" is only true for extensions that intercept all requests all the time like ad-blockers on a slow device like a mobile phone, but even then it doesn't apply to extensions that use a URL filter that matches once a day or even less - there are lots of such extensions broken in MV3 with no workaround. The proper solution would be to encourage the switch to declarativeNetRequest but also add more filters to webRequestBlocking (both from DNR and from chrome.declarativeContent) so the browser doesn't have to block its network requests just for the extension to tell it's not interested, and add quotas to limit the usage of webRequestBlocking to only the unavoidable cases.
  
  
• "service worker is a step forward for the extensions platform" is true only in one super rare case where the extension's main thread is blocked by super heavy DOM all the time and it simultaneously listens to frequent events (imagine devtools being implemented as an extension), but as this technology is designed to load web sites faster not as a generic background process it also makes 10+ steps back by breaking essential language features (dynamic imports) and lots of built-in APIs with no solution in sight other than the super wasteful offscreen document workaround that consumes ~20MB of memory just to create a new context and serialize/deserialize potentially big messages twice (request and response).
  
  
• "declarativeNetRequest covers most cases for webRequestBlocking" is largely false as DNR was designed to solve one major case (filter lists used by ad-blockers) that suffered from webRequestBlocking performance problems mentioned above the most. While DNR also helps in tons of trivial sub-cases doesn't mean that the sheer quantity of these somehow makes the non-covered major cases negligible.