Dynamically load JS in devtools with Manifest V3

[Mengdi Chen]

Hi everyone,

I'm working with React.js team to build a new React Developer Tools extension. Since React developers might be using different versions, it needs to support all of them.

For engineering benefits, we would prefer to load a different React DevTools runtime for every React version (instead of one runtime for all versions). Natively we can bundle the runtime files all into the extension, but over time the extension will get too large.

Ideally, we want to dynamically download and execute a matching JS from our CDN for the current React version that runs on the page the user is inspecting. My understanding is that this is possible with Manifest V2, but no longer possible with V3. Is this true? If so, is there an alternative way to achieve my goal?

Thanks,

Mengdi

[Deco]

You are indeed correct to assume that this method is not possible with MV3. As of MV3, all scripts must be stored locally rather than being downloaded from a CDN. I'm not aware of any other possible solution to your problem as it directly violates the CSP in some? form if tried.

A bit of a workaround is to only load the scripts which match when done locally, there isn't a way around the big size issue however.

Thanks,

Decklin

--
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/3cd29280-2249-4dca-8cbd-691ece24371bn%40chromium.org.

[Deco]

On further thought, what you can do is segregate your CRX's according to version provisioning, that is loading the script for e.g. V1-2 on one extension, 2-3 on another and so forth. 

This does mean you'll have more than one extension, but it's a workaround to your size issue.

Thanks,

Decklin

[Mengdi Chen]

Thanks for the advices Decklin! I'll explore some other options

[Mengdi Chen]

Looks like it is possible to load script tag from CDN on the page (not in the extension) via `chrome.devtools.inspectedWindow.eval`. Can you confirm if this is correct? If so, at least I can move the content scripts I currently inject to the page (via `chrome.scripting.registerContentScripts`) to a CDN.

[wOxxOm]

inspectedWindow.eval simply runs in the MAIN world of the page (by default), so it is governed by the CSP of the page, not of the extension's ISOLATED world of the content scripts.

It's the same as running code in the MAIN world via chrome.scripting API, and then creating a script element inside that code.

Both methods are "forbidden" in the web store although malware extensions will abuse it easily because it's impossible to detect reliably via automatic tools.

[Mengdi Chen]

Hi folks,

One thing I overlooked for a while was that we might to have to make changes in the React DevTools backend ("runtime") in prereleases (nightly / experimental / beta builds). Since it's impossible for us to update the extension in the Chrome Web Store as frequently, I need to explore a bit more on this topic. 

Is it OK to show users a button so they can proactively trigger the download action? We can clearly show them the URL, and encourage (and instruct) users to load it from their own host (e.g. current origin).

Thanks!

Mengdi

[Mengdi Chen]

I can further limit the allowed domain to localhost, if that is allowed.

If that's not allowed, I guess my only option is to tell React power users to download, unpack, and load the extension they need  instead of using Chrome web store.  

[Simeon Vincent]

Both methods [inspectedWindow.eval and chrome.scripting] are "forbidden" in the web store although malware extensions will abuse it easily because it's impossible to detect reliably via automatic tools.

That's not right. While the text of the Additional Requirements for Manifest V3 policy does not allow any kind of evaluation, it's permissible for debugging tools and developer tools to use devtools.inspectedWindow.eval() and Runtime.evaluate (via Debugger API) to inject scripts into pages. These tools should still use dynamic scripts where possible in order to help keep users safe, but this exception aims to enable workflows that wouldn't otherwise be possible for users that better understand and accept the risks associated with arbitrary script execution.

That exception should be called out in the policy text. As I recall it wasn't include when this policy was first introduced for time reasons. After I send this I'll follow up with my Chrome contacts to request an update.

Mengdi, I'd be happy to chat more about your use case. I'll follow up with you in another email.

Simeon - @dotproto

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/4704663a-908c-4106-be60-9e86ac80cb44n%40chromium.org.