Tag: Extensions

How to Transition to Manifest V3 for Chrome Extensions

While I am not a regular Chrome extension programmer, I have certainly coded enough extensions and have a wide enough web development portfolio to know my way around the task. However, just recently, I had a client reject one of my extensions as I received feedback that my extension was “outdated”.

As I was scrambling to figure out what was wrong, I swept my embarrassment under the carpet and immediately began my deep dive back into the world of Chrome Extensions. Unfortunately, information on Manifest V3 was scarce and it was difficult for me to understand quickly what this transition was all about.

Needless to say, with a pending job, I had to painstakingly navigate my way around Google’s Chrome Developer Documentation and figure things out for myself. While I got the job done, I did not want my knowledge and research in this area to go to waste and decided to share what I wish I could have had easy access to in my learning journey.

Why the transition to Manifest 3 is important

Manifest V3 is an API that Google will use in its Chrome browser. It is the successor to the current API, Manifest V2, and governs how Chrome extensions interact with the browser. Manifest V3 introduces significant changes to the rules for extensions, some of which will be the new mainstay from V2 we were used to.

The transition to Manifest V3 can be summarized as such:

  1. The transition has been ongoing since 2018.
  2. Manifest V3 will officially begin rolling out in January 2023.
  3. By June 2023, extensions that run Manifest V2 will no longer be available on the Chrome Web Store.
  4. Extensions that do not comply with the new rules introduced in Manifest V3 will eventually be removed from the Chrome Web Store.

One of the main goals of Manifest V3 is to make users safer and improve the overall browser experience. Previously, many browser extensions relied on code in the cloud, meaning it could be difficult to assess whether an extension was risky. Manifest V3 aims to address this by requiring extensions to contain all the code they will run, allowing Google to scan them and detect potential risks. It also forces extensions to request permission from Google for the changes they can implement on the browser.

Staying up-to-date with Google’s transition to Manifest V3 is important because it introduces new rules for extensions that aim to improve user safety and the overall browser experience, and extensions that do not comply with these rules will eventually be removed from the Chrome Web Store.

In short, all of your hard work in creating extensions that used Manifest V2 could be for naught if you do not make this transition in the coming months.

January 2023 June 2023 January 2024
Support for Manifest V2 extensions will be turned off in Chrome’s Canary, Dev, and Beta channels. The Chrome Web Store will no longer allow Manifest V2 extensions to be published with visibility set to Public. The Chrome Web Store will remove all remaining Manifest V2 extensions.
Manifest V3 will be required for the Featured badge in the Chrome Web Store. Existing Manifest V2 extensions that are published and publically visible will become unlisted. Support for Manifest 2 will end for all of Chrome’s channels, including the Stable channel, unless the Enterprise channel is extended.

The key differences between Manifest V2 and V3

There are many differences between the two, and while I highly recommend that you read up on Chrome’s “Migrating to Manifest V3” guide, here is a short and sweet summary of key points:

  1. Service workers replace background pages in Manifest V3.
  2. Network request modification is handled with the new declarativeNetRequest API in Manifest V3.
  3. In Manifest V3, extensions can only execute JavaScript that is included within their package and cannot use remotely-hosted code.
  4. Manifest V3 introduces promise support to many methods, though callbacks are still supported as an alternative.
  5. Host permissions in Manifest V3 are a separate element and must be specified in the "host_permissions" field.
  6. The content security policy in Manifest V3 is an object with members representing alternative content security policy (CSP) contexts, rather than a string as it was in Manifest V2.

In a simple Chrome Extension’s Manifest that alters a webpage’s background, that might look like this:

// Manifest V2 {   "manifest_version": 2,   "name": "Shane's Extension",   "version": "1.0",   "description": "A simple extension that changes 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,   "name": "Shane's Extension",   "version": "1.0",   "description": "A simple extension that changes the background of a webpage to Shane's face.",   "background": {     "service_worker": "background.js"   },   "action": {     "default_popup": "popup.html"   },   "permissions": [ "activeTab", ],   "host_permissions": [ "<all_urls>" ] }

If you find some of the tags above seem foreign to you, keep reading to find out exactly what you need to know.

How to smoothly transition to Manifest V3

I have summarized the transition to Manifest V3 in four key areas. Of course, while there are many bells and whistles in the new Manifest V3 that need to be implemented from the old Manifest V2, implementing changes in these four areas will get your Chrome Extension well on the right track for the eventual transition.

The four key areas are:

  1. Updating your Manifest’s basic structure.
  2. Modify your host permissions.
  3. Update the content security policy.
  4. Modify your network request handling.

With these four areas, your Manifest’s fundamentals will be ready for the transition to Manifest V3. Let’s look at each of these key aspects in detail and see how we can work towards future-proofing your Chrome Extension from this transition.

Updating your Manifest’s basic structure

Updating your manifest’s basic structure is the first step in transitioning to Manifest V3. The most important change you will need to make is changing the value of the "manifest_version" element to 3, which determines that you are using the Manifest V3 feature set.

One of the major differences between Manifest V2 and V3 is the replacement of background pages with a single extension service worker in Manifest V3. You will need to register the service worker under the "background" field, using the "service_worker" key and specify a single JavaScript file. Even though Manifest V3 does not support multiple background scripts, you can optionally declare the service worker as an ES Module by specifying "type": "module", which allows you to import further code.

In Manifest V3, the "browser_action" and "page_action" properties are unified into a single "action" property. You will need to replace these properties with "action" in your manifest. Similarly, the "chrome.browserAction" and "chrome.pageAction" APIs are unified into a single “Action” API in Manifest V3, and you will need to migrate to this API.

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

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

Overall, updating your manifest’s basic structure is a crucial step in the process of transitioning to Manifest V3, as it allows you to take advantage of the new features and changes introduced in this version 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 in the "permissions" field in the manifest file. In Manifest V3, host permissions are a separate element, and you should specify them in the "host_permissions" field in the manifest file.

Here is an example of how to 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": [    ":///*"  ]

Update the content security policy

In order to update the CSP of your Manifest V2 extension to be compliant with Manifest V3, you will need to make some changes to your manifest file. In Manifest V2, the CSP was specified as a string in the "content_security_policy" field of the manifest.

In Manifest V3, the CSP is now an object with different members representing alternative CSP contexts. Instead of a single "content_security_policy" field, you will now have to specify separate fields for "content_security_policy.extension_pages" and "content_security_policy.sandbox", depending on the type of extension pages you are using.

You should also remove any references to external domains in the "script-src", "worker-src", "object-src", and "style-src" directives if they are present. It is important to make these updates to your CSP in order to ensure the security 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://example.com; object-src 'self'", "content_security_policy.sandbox": "script-src 'self' https://css-tricks.com; object-src 'self'"

Modify your network request handling

The final step in transitioning to Manifest V3 is modifying your network request handling. In Manifest V2, you would have used the chrome.webRequest API to modify network requests. However, this API is replaced in Manifest V3 by the declarativeNetRequest API.

To use this new API, you will need to specify the declarativeNetRequest permission in your manifest and update your code to use the new API. One key difference between the two APIs is that the declarativeNetRequest API requires you to specify a list of predetermined addresses to block, rather than being able to block entire categories of HTTP requests as you could with the chrome.webRequest API.

It is important to make these changes in your code to ensure that your extension continues to function properly under Manifest V3. Here is an example of how you would modify your manifest to use the declarativeNetRequest API in Manifest V3:

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

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

You will also need to update your extension code to use the declarativeNetRequest API instead of the chrome.webRequest API.

Other aspects you need to check

What I have covered is just the tip of the iceberg. Of course, if I wanted to cover everything, I could be here for days and there would be no point in having Google’s Chrome Developers guides. While what I covered will have you future-proofed enough to arm your Chrome extensions in this transition, here are some other things you might want to look at to ensure your extensions are functioning at the top of their game.

  • Migrating background scripts to the service worker execution context: As mentioned earlier, Manifest V3 replaces background pages with a single extension service worker, so it may be necessary to update background scripts to adapt to the service worker execution context.
  • Unifying the **chrome.browserAction** and **chrome.pageAction** APIs: These two equivalent APIs are unified into a single API in Manifest V3, so it may be necessary to migrate to the Action API.
  • Migrating functions that expect a Manifest V2 background context: The adoption of service workers in Manifest V3 is not compatible with methods like chrome.runtime.getBackgroundPage(), chrome.extension.getBackgroundPage(), chrome.extension.getExtensionTabs(), and chrome.extension.getViews(). It may be necessary to migrate to a design that passes messages between other contexts and the background service worker.
  • Moving CORS requests in content scripts to the background service worker: It may be necessary to move CORS requests in content scripts to the background service worker in order to comply with Manifest V3.
  • Migrating away from executing external code or arbitrary strings: Manifest V3 no longer allows the execution of external logic using chrome.scripting.executeScript({code: '...'}), eval(), and new Function(). It may be necessary to move all external code (JavaScript, WebAssembly, CSS) into the extension bundle, update script and style references to load resources from the extension bundle, and use chrome.runtime.getURL() to build resource URLs at runtime.
  • Updating certain scripting and CSS methods in the Tabs API: As mentioned earlier, several methods move from the Tabs API to the Scripting API in Manifest V3. It may be necessary to update any calls to these methods to use the correct Manifest V3 API.

And many more!

Feel free to take some time to get yourself up to date on all the changes. After all, this change is inevitable and if you do not want your Manifest V2 extensions to be lost due to avoiding this transition, then spend some time arming yourself with the necessary knowledge.

On the other hand, if you are new to programming Chrome extensions and looking to get started, a great way to go about it is to dive into the world of Chrome’s Web Developer tools. I did so through a course on Linkedin Learning, which got me up to speed pretty quickly. Once you have that base knowledge, come back to this article and translate what you know to Manifest V3!

So, how will I be using the features in the new Manifest V3 going forward?

Well, to me, the transition to Manifest V3 and the removal of the chrome.webRequest API seems to be shifting extensions away from data-centric use cases (such as ad blockers) to more functional and application-based uses. I have been staying away from application development lately as it can get quite resource-intensive at times. However, this shift might be what brings me back!

The rise of AI tools in recent times, many with available-to-use APIs, has sparked tons of new and fresh SaaS applications. Personally, I think that it’s coming at a perfect time with the shift to more application-based Chrome extensions! While many of the older extensions may be wiped out from this transition, plenty of new ones built around novel SaaS ideas will come to take their place.

Hence, this is an exciting update to hop on and revamp old extensions or build new ones! Personally, I see many possibilities in using APIs that involve AI being used in extensions to enhance a user’s browsing experience. But that’s really just the tip of the iceberg. If you’re looking to really get into things with your own professional extensions or reaching out to companies to build/update extensions for them, I would recommend upgrading your Gmail account for the benefits it gives in collaborating, developing, and publishing extensions to the Chrome Web Store.

However, remember that every developer’s requirements are different, so learn what you need to keep your current extensions afloat, or your new ones going!

How to Transition to Manifest V3 for Chrome Extensions originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.


, , ,

Our favorite Chrome extensions of 2021

I hadn’t heard of most of the Chrome extensions that Sarem Gizaw lists as 2021 favorites. Here are my hot takes on all of them, except the virtual learning specific ones that aren’t very relevant to me.

Browser extensions have come a long way toward being cross-browser compatible, so I’d think a lot of these are available for Safari and Firefox now—or at least could be without enormous amounts of work if the authors felt like doing it.

Notably, there are no ad blocker plugins in the list. Not a huge surprise there, even though I’m sure they are some of the most-downloaded and used. I use Ghostery, but I haven’t re-evaluated the landscape there in a while. I like how Ghostery makes it easy for me to toggle on-and-off individual scripts, both on individual sites and broadly across all sites. That means I could enable BuySellAds (something even Adblock Plus does by default) and Google Analytics scripts, but turn off A/B testers or gross ad networks.

To Shared LinkPermalink on CSS-Tricks


, , ,

VS Code Extensions for HTML

Let’s look at some extensions for VS Code that make writing and editing HTML (and languages that are basically HTML with extra powers) better. You may not like all of them. Maybe some of them don’t appeal to you, solve a problem you don’t have, or feel like more clutter than you need. That’s OK. These are just a handful that I’ve tried and liked to some degree.

I’d start with Emmet here, even thought it’s not technically an extension1 for VS Code. It’s built right in. You should know about it though because it’s very useful. It does “HTML Expansions” like this, which I use pretty much every day of my life:

HTML End Tag Labels

I heard about this one from Stefan Judis who blogged about it the other day and inspired this post idea.

The whole idea is that rather than you leaving comments in your HTML to indicate what HTML element it is closing (a somewhat common practice, especially for partials that close elements that might not be opened in the same document).

<div class="main">   </div> <!-- / div.main -->  <?php /* / div.main */ ?> <?php /* Sometimes I'd do it in a server side language so it didn't go over the wire. */ ?>

This extension shows you UI about what HTML is being closed:

Auto Close Tag

As soon as you type the > in an HTML element, like the last bracket in <div>, the closing tag is automatically created for you.

It can be configured to only auto close after you’ve typed the </ to indicate you’re about to close a tag, which is a default in Sublime Text 3. Speaking of which, if you install the Sublime Text Keymap, you’d get that automatically, plus a handful of other fancy key commands.

There is also Close HTML/XML tag, but it only works via key command. With Auto Close Tag you can configure it either way, and it has far more installs for whatever reason.

Highlight Matching Tag

Here’s the GIF from their docs:

I was going to do my own video, but I discovered that even if I have this extension off, something else in my VS Code is highlighting matching tags anyway. I’m not entirely sure what it is, which leads me to believe it might be a built-in feature now.

What I see without this extension on: a border around the matching tags.

Not specific to HTML, but if like this sort of help with matching things, you might give Bracket Pair Colorizer 2 a try, which can be quite nice for CSS and JavaScript.

Auto Rename Tag

I find this one quite useful!

I believe this functionality is actually built into the canonical Emmet, but again, VS Code doesn’t use canonical Emmet so this feature isn’t there, hence the need for this extra plugin.

Better Comments

I leave code comments fairly liberally, especially when dev’ing out new things. A convention I like is when a comment is prefixed (e.g. TODO) that it is extra important and needs attention. Better Comments allows those to look visually different.

Code Spell Checker

There is no spell-checking in VS code. I don’t love that. To me this plugin is a must-have, especially for HTML, because HTML typically has content in it, like words, that should be spelled correctly. And just like a linter, this plugin gives you squiggles when something is wrong and a menu to attempt to fix it.

Indent Rainbow

Bask in this glorious rainbow created by deepening indents:

The point is that it gives you some visual cues to what level you’re currently looking/working at. In that sense it’s kinda like the Highlight Matching Tag, but I like them both honestly. It’s most useful when you need to scroll up or down to find where the matching tag is.


Prettier does work on HTML, but I’d almost call it a smidge controversial. For example, it breaks HTML attributes onto single lines which feels a lot like a JSX thing but less common to see in raw HTML. But sometimes there are literal side effects. Like if you type <ul><li></li><li></li></ul> on purpose like that (no whitespace) because you’re going to set all the list items inline, Prettier will break them onto their own lines, inserting whitespace, and changing the layout of what you intend. You can always fix it with a comment for Prettier to leave it alone (e.g. {/* prettier-ignore */}), but I could see it rubbing people the wrong way. There are even settings for it under HTML Whitespace Sensitivity, but it could never be perfect.

I actually got Prettier for HTML working just for this blog post so I think I’ll keep it for a while and see if I like it. I already know I like Prettier for JSX. I’m generally for as much autoformatting as possible.


I gotta imagine there are lots of snippet plugins, but this is the only one I’ve tried and it works fine. I like how you make snippets right from existing files.


I heard about this one from Kyle Simpson who I think was doing some paid consulting with them or something. The point of it is that it does fancy AI-powered autocomplete suggestions, even in HTML. Check out it guessing at some attributes:

This looks like a pretty commercial product with features that push you toward paid plans for teams. I don’t really feel like getting all into that; it was just interesting to see a tool like this work with HTML.

axe Accessibility Linter

This lints your HTML for accessibility problems right in the editor. There are a bunch of rules it checks for.

  1. Did you know even though VS Code has Emmet baked right in, there is no communication between Emmet’s creator and the VS Code team? I’ve tried to facilitate that connection in the past, but failed. Point being: Emmet in VS Code would probably be better if it wasn’t just jacked in but integrated from the official packages. Emmet has new things that VS Code could use, like expansion previews.

The post VS Code Extensions for HTML appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, ,

My Visual Studio Code Setup: Extensions and Themes

Matthias Ott’s posted his VS Code setup. I find lists like this (I rounded up some recent updates of my own) irresistible, probably because, like y’all, I spend an awful lot of time in VS Code and wanna make sure I’m getting the most out of it.

Things from the list that stood out to me:

  • I didn’t realize Bracket Pair Colorizer had gone v2 and it’s a separate install.
  • I din’t realize you needed an extension to honor .editorconfig files.
  • I wasn’t using anything for PHP, but Matthias listed PHP Intelephense and I’m giving it a whirl. It has fewer users than the non-weirdly named one though? And when I installed that, I saw Format HTML in PHP which I’m also trying because, yes, please! (Even Prettier’s PHP add-on can’t do that.)

Messing with extensions is also a good opportunity to clear out old crap.

Also super interesting…

The main point of that series is cleaning up the interface of VS Code in extreme ways. All the way down to:

Direct Link to ArticlePermalink

The post My Visual Studio Code Setup: Extensions and Themes appeared first on CSS-Tricks.


, , , , ,