Migrating to manifest v3

This post is not a migration guide. Google has published one here. The goal is to raise awareness among extension owners. The idea is to understand the impacts and the efforts required.

Are you concerned ? 

Well, as of Jan 2022, you can't post a manifest v2 based extension on the Chrome Web Store (CWS) and by end of 2022, all extensions should have been migrated. Official Google timeline is here. So the question is more about the severity of changes you need to bring in and when you need to start the efforts. This depends on:
- the complexity of your addon, its architecture and the balance of responsibilities between content and background scripts
- the amount of chrome APIs deprecated in V3
- the usage of chrome APIs that are not available or not ready yet in V3.
- the usage of DOM based APIs 

Note: you can still distribute V2 extensions till June 2023 if you don't host your extension on CWS and force deployment thru Google Enterprise policy.

Service workers

Architecture is by far the most important aspect in the migration. V3 replaces background script (the persistent version) by service workers (SW). From a lifecycle perspective, an active SW dies automatically after 30  seconds in the absence of messaging. After dying, SW is woken up by messages arising from content scripts and will start from scratch.
This requires to manually implement:
- data persistency
- connexion to external resources

As a consequence, the concept of background script driven extension is dead. There is no certainty for a periodic process implemented thru setTimeOut/setTimeInterval to be triggered. 

Note: some have proposed workarounds to keep the SW alive such as opening a long term comm port between content script and SW. But this requires at least one tab with a content script. 

DOM based APIs

Service workers have no access to standard dom APIs. Consequently, you will have to move certain functions to content scripts or find replacement for certain APIs (ex: xmlHttpRequest by fetch). Forget about creating dom elements in the SW or parsing some html content you'd receive from your backend.  

Intercepting http requests

WebRequest API is being deprecated. Let' be clear, the blocking part of this API is deprecated. That's the number 2 motivation for Google to come up with V3.  With the new API called declarativeNetworkRequest, we step away from a flexible programatic method to the declaration of static rules for processing http headers.  

Remote code execution

Well, loading Javascript from remote locations won't be possible anymore and that's a good thing for protecting from malignant people. Adversely,  swiss knife types of extensions like TamperMonkey are doomed. 
Concretely, it is not possible to call eval(), new Function() or the powerful chrome.tabs.executeScript in the SW. Instead a more constrained API, chrome.scripting takes an extension packaged JS file as argument.

Deprecated chrome APIs

A set of chrome APIs are deprecated in V3. You should check if your extension uses one of those.  I'll mention chrome.extension.getURL but the list is available here

For more information about V3, please check google documentation here.

What's next:

This post reflects the current status of V3 (at the time of writing). There are cross-browser discussions led by the WebExtensions Community Group (WECG). You can follow those here.



Comments

Post a Comment

Popular posts from this blog

Extending an extension with a native app.

Usecase I've recently come across a specific requirement from a customer who wanted a chrome extension  fiddling with the user machine file system. To be more specific, the addon was supposed to allow for the download of a cloud-based compressed file, decompress it and place the result in a specific directory for consumption by another application. As many know, filesystem is sandboxed by chrome for security reasons and it is impossible per design to write files on the user machine outside of the control of the user. I ended-up with a specific architecture outsourcing of the unauthorized job to a native app which bears none of the constraints a chrome extension does. An elegant architecture NativeMessaging Chrome API allows an extension to control - ie launch,communicate with and close - an external application: Native application can be written in any language An instance of the native app is launched when the extension connects to a configured service Native app  recei
Read more

Intercepting file download in chrome

Here is a little JS snippet which prevents every file download  (and accessorily opens a new tab in Gsuite for attempts to download from the Gsuite):   chrome.downloads.onCreated.addListener(downloadItem => {       chrome.downloads.cancel( downloadItem.id, ()=>{         alert("DL canceled: "+downloadItem.finalUrl);         if (downloadItem.finalUrl.search("https://docs.google.com")!=-1){           var _driveUrl = downloadItem.finalUrl.replace(/export\?.*/,"");           chrome.tabs.create({url:_driveUrl}, ()=>{});         }       })   });
Read more