Chrome Manifest V3 questions regarding service workers and dynamic javascript content

[Mile Djokic]

Hello,  
 
we have an extension which allows us to automate the browser for testing purposes, this extension only works in conjunction with the Tricentis Tosca.  
 
https://chrome.google.com/webstore/detail/tosca-automation-extensio/njjjlolnnicemgigahffncnddbioccpo  
 
We had a first look into the new chrome Manifest V3.  
Unfortunately, we found out that some main functions of our extension won’t work with the new manifest version.   
We have encountered the following issues until now, and would ask if there are known workarounds to achieve the same results? 

 

Loading of dynamic java script: 
 
You are stating that there is no more execution of dynamic scripts in the content scripts of the extension. This is critical for us since we have functions to execute Javascript content, where the content is created dynamically outside the content script of the extension and then executed over the extension.  
 

We found out that Tampermonkey was running into the same issues but resolved it. 
https://github.com/Tampermonkey/tampermonkey/issues/644. Unfortunately, it is not explained how it was solved.  
Do you have any input on this? 
 
Service Workers:  
 
Also, we are facing some issues with the Service Workers since they get recycled after some time. 
 
1.Currently our background page opens a websocket connection to a websocket server running in a local Windows service and registers itself in this service as an available Chrome instance. This connection is necessary because we want to control Chrome from Tosca. Now the question is how we can implement this in the new Serviceworker concept since the connection is disconnected when the Serviceworker is recycled. 

2. Our background page currently holds some caches that we can't easily persist to the local storage, since the objects in those caches are not primitive types. Here we need to find out if these cached objects can be changed to be recreated from the local storage. 

Thanks, 
Mile Djokic 

 

 

[hrg...@gmail.com]

The Extensions team in charge of the MV3 transition has mentioned a number of times that extensions will be able to execute arbitrary Javascript.

However, as far as I know, they still haven't informed the community how this is going to be possible.

I remember Simeon Vincent said some time ago that they want to have MV3 in a working state first. Then they will reveal the mechanism for arbitrary code execution, which will require some form user authorization.

This is the same they told the author of Tampermonkey. That is, user scripts managers and similar extensions will continue to work in MV3 but the user will have to do some action in order for the extension to be granted such permission.

[wOxxOm]

>  Currently our background page opens a websocket connection to a websocket server running in a local Windows service and registers itself in this service as an available Chrome instance. This connection is necessary because we want to control Chrome from Tosca. Now the question is how we can implement this in the new Serviceworker concept since the connection is disconnected when the Serviceworker is recycled  

There's an inherent limit in service workers - five minutes for any external connection, see and star https://crbug.com/1152255. Let's hope this limit will be removed because it makes no sense for extensions as they aren't web sites and their usage patterns are completely different.

> Our background page currently holds some caches that we can't easily persist to the local storage, since the objects in those caches are not primitive types. Here we need to find out if these cached objects can be changed to be recreated from the local storage. 

The Chromium extensions team wants extensions to recreate the state each time their background script starts even if it happens hundreds times a day because they believe it will magically spend less CPU/battery/resources compared to a passively waiting persistent background script. If you don't believe in magic, you'll have to prevent the service worker from unloading by opening a messaging port from any tab's content script or from another page of the extension. This port will live for five minutes currently so listen to the port's onDisconnect event and reconnect with some random tab again. The downside is the need for broad host permissions and the need for at least one tab with a web page to run the content script. Let's hope that Chromium team provides an API to control the lifetime of the worker someday.

The second workaround is endorsed by the Chromium extensions team - open a visible page of your extension in a tab and let it do everything your old background script could do. To reduce the probability of annoying your users by this backward kludge you can display something interesting in that tab like a status log or a chart/graph for whatever your extension does. Don't forget to add a listener for `beforeunload` to prevent accidental closing of the tab.