The way to Transition to Manifest V3 for Chrome Extensions | CSS-Tips

Whereas I’m not an everyday Chrome extension programmer, I’ve definitely coded sufficient extensions and have a large sufficient net improvement portfolio to know my approach across the activity. Nonetheless, only in the near past, I had a consumer reject certainly one of my extensions as I obtained suggestions that my extension was “outdated”.

As I used to be scrambling to determine what was unsuitable, I swept my embarrassment below the carpet and instantly started my deep dive again into the world of Chrome Extensions. Sadly, info on Manifest V3 was scarce and it was tough for me to know shortly what this transition was all about.

For sure, with a pending job, I needed to painstakingly navigate my approach round Google’s Chrome Developer Documentation and determine issues out for myself. Whereas I acquired the job executed, I didn’t need my data and analysis on this space to go to waste and determined to share what I want I may have had quick access to in my studying journey.

Why the transition to Manifest 3 is essential

Manifest V3 is an API that Google will use in its Chrome browser. It’s the successor to the present API, Manifest V2, and governs how Chrome extensions work together with the browser. Manifest V3 introduces vital modifications to the principles for extensions, a few of which would be the new mainstay from V2 we had been used to.

The transition to Manifest V3 will be summarized as such:

1. The transition has been ongoing since 2018.
2. Manifest V3 will formally start rolling out in January 2023.
3. By June 2023, extensions that run Manifest V2 will now not be out there on the Chrome Internet Retailer.
4. Extensions that don’t adjust to the brand new guidelines launched in Manifest V3 will finally be faraway from the Chrome Internet Retailer.

One of many predominant targets of Manifest V3 is to make customers safer and enhance the general browser expertise. Beforehand, many browser extensions relied on code within the cloud, which means it might be tough to assess whether or not an extension was dangerous. Manifest V3 goals to handle this by requiring extensions to include all of the code they may run, permitting Google to scan them and detect potential dangers. It additionally forces extensions to request permission from Google for the modifications they will implement on the browser.

Staying up-to-date with Google’s transition to Manifest V3 is essential as a result of it introduces new guidelines for extensions that goal to enhance consumer security and the general browser expertise, and extensions that don’t adjust to these guidelines will finally be faraway from the Chrome Internet Retailer.

Briefly, all your arduous work in creating extensions that used Manifest V2 might be for naught if you don’t make this transition within the coming months.

The important thing variations between Manifest V2 and V3

There are numerous variations between the 2, and whereas I extremely advocate that you just learn up on Chrome’s “Migrating to Manifest V3” information, here’s a quick and candy abstract of key factors:

1. Service employees change background pages in Manifest V3.
2. Community request modification is dealt with with the brand new declarativeNetRequest API in Manifest V3.
3. In Manifest V3, extensions can solely execute JavaScript that’s included inside their package deal and can’t use remotely-hosted code.
4. Manifest V3 introduces promise help to many strategies, although callbacks are nonetheless supported in its place.
5. Host permissions in Manifest V3 are a separate ingredient and have to be specified within the "host_permissions" discipline.
6. The content material safety coverage in Manifest V3 is an object with members representing different content material safety coverage (CSP) contexts, relatively than a string because it was in Manifest V2.

In a easy Chrome Extension’s Manifest that alters a webpage’s background, which may appear to be this:

// Manifest V2
{
  "manifest_version": 2,
  "title": "Shane's Extension",
  "model": "1.0",
  "description": "A easy extension that modifications the background of a webpage to Shane's face.",
  "background": {
    "scripts": ["background.js"],
    "persistent": true
  },
  "browser_action": {
    "default_popup": "popup.html"
  },
  "permissions": [ "activeTab", ],
  "optional_permissions": ["<all_urls>"]
}

// Manifest V3
{
  "manifest_version": 3,
  "title": "Shane's Extension",
  "model": "1.0",
  "description": "A easy extension that modifications the background of a webpage to Shane's face.",
  "background": {
    "service_worker": "background.js"
  },
  "motion": {
    "default_popup": "popup.html"
  },
  "permissions": [ "activeTab", ],
  "host_permissions": [ "<all_urls>" ]
}

Should you discover a number of the tags above appear international to you, hold studying to search out out precisely what it is advisable know.

The way to easily transition to Manifest V3

I’ve summarized the transition to Manifest V3 in 4 key areas. In fact, whereas there are a lot of bells and whistles within the new Manifest V3 that have to be applied from the previous Manifest V2, implementing modifications in these 4 areas will get your Chrome Extension properly heading in the right direction for the eventual transition.

The 4 key areas are:

1. Updating your Manifest’s fundamental construction.
2. Modify your host permissions.
3. Replace the content material safety coverage.
4. Modify your community request dealing with.

With these 4 areas, your Manifest’s fundamentals will probably be prepared for the transition to Manifest V3. Let’s take a look at every of those key features intimately and see how we are able to work in direction of future-proofing your Chrome Extension from this transition.

Updating your Manifest’s fundamental construction

Updating your manifest’s fundamental construction is step one in transitioning to Manifest V3. A very powerful change you have to to make is altering the worth of the "manifest_version" ingredient to 3, which determines that you’re utilizing the Manifest V3 function set.

One of many main variations between Manifest V2 and V3 is the substitute of background pages with a single extension service employee in Manifest V3. You will have to register the service employee below the "background" discipline, utilizing the "service_worker" key and specify a single JavaScript file. Despite the fact that Manifest V3 doesn’t help a number of background scripts, you possibly can optionally declare the service employee as an ES Module by specifying "kind": "module", which lets you import additional code.

In Manifest V3, the "browser_action" and "page_action" properties are unified right into a single "motion" property. You will have to switch these properties with "motion" in your manifest. Equally, the "chrome.browserAction" and "chrome.pageAction" APIs are unified right into a single “Motion” API in Manifest V3, and you have to emigrate to this API.

// Manifest V2
"background": {
  "scripts": ["background.js"],
  "persistent": false
},
"browser_action": {
  "default_popup": "popup.html"
},

// Manifest V3
"background": {
  "service_worker": "background.js"
},
"motion": {
  "default_popup": "popup.html"
}

Total, updating your manifest’s fundamental construction is a vital step within the means of transitioning to Manifest V3, because it means that you can reap the benefits of the brand new options and modifications launched on this model of the API.

Modify your host permissions

The second step in transitioning to Manifest V3 is modifying your host permissions. In Manifest V2, you specify host permissions within the "permissions" discipline within the manifest file. In Manifest V3, host permissions are a separate ingredient, and you need to specify them within the "host_permissions" discipline within the manifest file.

Right here is an instance of how one can modify your host permissions:

// Manifest V2
"permissions": [ 
  "activeTab", 
  "storage", 
  "http://www.css-tricks.com/", 
  ":///*" 
]

// Manifest V3
"permissions": [ 
  "activeTab", 
  "scripting", 
  "storage"
],
"host_permissions": [
  "http://www.css-tricks.com/" 
],
"optional_host_permissions": [ 
  ":///*" 
]

Replace the content material safety coverage

To be able to replace the CSP of your Manifest V2 extension to be compliant with Manifest V3, you have to to make some modifications to your manifest file. In Manifest V2, the CSP was specified as a string within the "content_security_policy" discipline of the manifest.

In Manifest V3, the CSP is now an object with totally different members representing different CSP contexts. As an alternative of a single "content_security_policy" discipline, you’ll now must specify separate fields for "content_security_policy.extension_pages" and "content_security_policy.sandbox", relying on the kind of extension pages you’re utilizing.

You also needs to take away any references to exterior domains within the "script-src", "worker-src", "object-src", and "style-src" directives if they’re current. It is very important make these updates to your CSP so as to make sure the safety and stability of your extension in Manifest V3.

// Manifest V2
"content_security_policy": "script-src 'self' https://css-tricks.com; object-src 'self'"

// Manfiest V3
"content_security_policy.extension_pages": "script-src 'self' https://instance.com; object-src
'self'",
"content_security_policy.sandbox": "script-src 'self' https://css-tricks.com; object-src 'self'"

Modify your community request dealing with

The ultimate step in transitioning to Manifest V3 is modifying your community request dealing with. In Manifest V2, you’ll have used the chrome.webRequest API to change community requests. Nonetheless, this API is changed in Manifest V3 by the declarativeNetRequest API.

To make use of this new API, you have to to specify the declarativeNetRequest permission in your manifest and replace your code to make use of the brand new API. One key distinction between the 2 APIs is that the declarativeNetRequest API requires you to specify an inventory of predetermined addresses to dam, relatively than having the ability to block whole classes of HTTP requests as you could possibly with the chrome.webRequest API.

It is very important make these modifications in your code to make sure that your extension continues to operate correctly below Manifest V3. Right here is an instance of how you’ll modify your manifest to make use of the declarativeNetRequest API in Manifest V3:

// Manifest V2
"permissions": [
  "webRequest",
  "webRequestBlocking"
]

// Manifest V3
"permissions": [
  "declarativeNetRequest"
]

Additionally, you will must replace your extension code to make use of the declarativeNetRequest API as a substitute of the chrome.webRequest API.

Different features it is advisable test

What I’ve lined is simply the tip of the iceberg. In fact, if I wished to cowl every part, I might be right here for days and there could be no level in having Google’s Chrome Builders guides. Whereas what I lined may have you future-proofed sufficient to arm your Chrome extensions on this transition, listed below are another stuff you may need to take a look at to make sure your extensions are functioning on the high of their sport.

• Migrating background scripts to the service employee execution context: As talked about earlier, Manifest V3 replaces background pages with a single extension service employee, so it could be essential to replace background scripts to adapt to the service employee execution context.
• Unifying the **chrome.browserAction** and **chrome.pageAction** APIs: These two equal APIs are unified right into a single API in Manifest V3, so it could be essential to migrate to the Motion API.
• Migrating capabilities that anticipate a Manifest V2 background context: The adoption of service employees in Manifest V3 isn’t appropriate with strategies like chrome.runtime.getBackgroundPage(), chrome.extension.getBackgroundPage(), chrome.extension.getExtensionTabs(), and chrome.extension.getViews(). It could be essential to migrate to a design that passes messages between different contexts and the background service employee.
• Shifting CORS requests in content material scripts to the background service employee: It could be essential to maneuver CORS requests in content material scripts to the background service employee so as to adjust to Manifest V3.
• Migrating away from executing exterior code or arbitrary strings: Manifest V3 now not permits the execution of exterior logic utilizing chrome.scripting.executeScript({code: '...'}), eval(), and new Perform(). It could be essential to maneuver all exterior code (JavaScript, WebAssembly, CSS) into the extension bundle, replace script and magnificence references to load assets from the extension bundle, and use chrome.runtime.getURL() to construct useful resource URLs at runtime.
• Updating sure scripting and CSS strategies within the Tabs API: As talked about earlier, a number of strategies transfer from the Tabs API to the Scripting API in Manifest V3. It could be essential to replace any calls to those strategies to make use of the right Manifest V3 API.

And plenty of extra!

Be happy to take a while to get your self updated on all of the modifications. In any case, this alteration is inevitable and if you do not need your Manifest V2 extensions to be misplaced as a result of avoiding this transition, then spend a while arming your self with the required data.

Then again, in case you are new to programming Chrome extensions and trying to get began, a good way to go about it’s to dive into the world of Chrome’s Internet Developer instruments. I did so by means of a course on Linkedin Studying, which acquired me up to the mark fairly shortly. After you have that base data, come again to this text and translate what you recognize to Manifest V3!

So, how will I be utilizing the options within the new Manifest V3 going ahead?

Properly, to me, the transition to Manifest V3 and the removing of the chrome.webRequest API appears to be shifting extensions away from data-centric use circumstances (such as advert blockers) to extra purposeful and application-based makes use of. I’ve been staying away from software improvement these days as it could get fairly resource-intensive at occasions. Nonetheless, this shift is likely to be what brings me again!

The rise of AI instruments in latest occasions, many with available-to-use APIs, has sparked tons of latest and recent SaaS functions. Personally, I feel that it’s coming at an ideal time with the shift to extra application-based Chrome extensions! Whereas most of the older extensions could also be worn out from this transition, loads of new ones constructed round novel SaaS concepts will come to take their place.

Therefore, that is an thrilling replace to hop on and revamp previous extensions or construct new ones! Personally, I see many prospects in utilizing APIs that contain AI being utilized in extensions to reinforce a consumer’s looking expertise. However that’s actually simply the tip of the iceberg. Should you’re trying to actually get into issues with your personal skilled extensions or reaching out to corporations to construct/replace extensions for them, I might advocate upgrading your Gmail account for the advantages it provides in collaborating, creating, and publishing extensions to the Chrome Internet Retailer.

Nonetheless, keep in mind that each developer’s necessities are totally different, so study what it is advisable hold your present extensions afloat, or your new ones going!