I could be very wrong about this, and yes, it's also mostly wishful thinking, but my guess is Chrome will have to walk back V3 at some point. The reasoning is that V3 makes uBlock Origin impossible, and Chrome without uBlock (or any browser really) is unusable.

So maybe you can just wait? Although it may take a long time.

Also, FF said in May of last year (2021) that they would start accepting V3 extensions in "early 2022" [0] but I don't know if they have kept their schedule.

[0] https://blog.mozilla.org/addons/2021/05/27/manifest-v3-updat...

I hope you're right. You're certainly right in my case: I will switch completely to FF when that happens. I was an early adopter of Chrome and while I do use FF quite a bit as my "work" profile, breaking extensions that make the web usable will cause me to leave and never look back (unless you are rate and the walk back v3)

I’ve wondered this as well, especially since the primary effect of the change appears to be undermining adblockers.

I could see Congress looking into a change like this, and hopefully an inquiry would be enough to get them to hold off.

Ah okay thanks for sharing the Mozilla update. And I suppose I am less optimistic than you, since they have so much browser market share I’d guess they’re happy to let devs figure out how to make our stuff work if we want access to their users. It’s also notable that so far v3 is only mandated for new extensions, though I’m not sure if that applies to updates of existing extensions.

It applies to updates of existing extensions in January 2023. https://developer.chrome.com/blog/mv2-transition/

It's axiomatic based on its self-evident nature.

Can you clarify? What is self evident? Plenty of people use Chrome without blockers. Maybe their browsing experience is subpar, but “unusable” is categorically false.

Taken from Merriam-Webster:

>not capable of being used or fit for use : not usable

And their example:

>The lavatory, totally unusable, was full of snow which had blasted in through the keyhole.

Which is categorically false of course because you can very well do your business before hypothermia sets in.

using a fork to eat soup is possible

Indeed. To stretch that analogy a bit further, spoons can be seen as a new technology which pushes the cost-benefit curve out. As with all new technologies, adoption can be gradual. For a time, lots of people will continue to eat soup with forks, until soup browsers begin shipping with spoons by default.

I used WebExtension polyfill[0] when adapting my FF addon to Chrome and admittedly all the intricate differences between APIs still costed me half a day of work.

I managed to have it done with only a few places where I branch on navigator.vendor, but If I wanted to ship different versions to AMO and CWS, I'd make use of something like DefinePlugin[1] for webpack to include/exclude code based on build target.

[0] https://github.com/mozilla/webextension-polyfill/

[1] https://github.com/webpack/docs/wiki/list-of-plugins#definep...

Yeah that’s the polyfill extension I use! Thanks for the validation, I am finding that I have to make manual changes anyway as well. Thanks for sharing the DefinePlugin, it looks like it could be quite useful

If you're familiar with Vue js, you should consider using Quasar[0]. It'll handle the compatability across browsers while you work on the extension.

[0] https://quasar.dev/quasar-cli/developing-browser-extensions/...

Is there anything like Quasar that supports React? (Question directed at the hive, not you specifically)

Ah interesting! I’ve written mine in Svelte (as far as the popup part goes) but this is a good resource if anyone sees this thread and uses Vue, thanks for sharing

My company's main products are browser extensions. At first, our Chrome extension was the most popular, but I anticipate with the upcoming changes we may say goodbye to Chrome and just be on Firefox and Safari, depending on how they deal with V3 issue. We simply don't make enough money from our Chrome extension to deal with all of their big changes. Last year they ditched the Webstore Payments, last summer they migrated Google Docs (one of our most popular use cases) from DOM to canvas-based rendering, and now this. We can't keep rewriting major parts of our codebase at the whim of big G.

> My company's main products are browser extensions

How well does the "WebExtensions API cross-browser technology" [0] work to build ONE code base and have to work well across Google Chrome, Firefox or even Safari?

[0] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

It has worked well for the last several years when we could easily deploy changes to Chrome and Firefox. I have no idea what we’re going to do with the upcoming manifest schism.

Safari is just mobile for us, though if Chrome goes through with V3 we may offer safari for desktop also.

> I have no idea what we’re going to do with the upcoming manifest schism

OK - is this issue then that the upcoming Chrome manifest changes break Chrome's compatibility with the standard or these were features that were never part of the standard to begin with and very specific to Chrome?

From talking with my dev, my understanding is this has to do with scripts and service workers. I believe these were not specific to Chrome previously, but I'm not sure.

I usually keep a common source folder for all browsers. This includes a common manifest (V2, still experimenting with V3). At build time a script generates a browser specific flavour of the manifest and copies all resources into a target folder (e.g /dist-chrome, /dist-safari, /dist-firefox) to create a bundle per browser and apply browser specific tweaks (like copying resources into an Xcode project for Safari etc).

How do you develop it (having the extension enabled in the browser) with this strategy? Are you just continuously re-building on changes and the browser picks it up?

Interesting! I’ve got something like that (doesn’t work properly for Chrome yet) going; if it is open source on git somewhere, I’d love to see it. If not, no worries!

Unless something changed in the past 3 weeks, you can still upload manifest V2 plugins to chrome, I uploaded one a few weeks ago.

Otherwise, what I did to support v2 for firefox and v3 for chrome is fairly straightforward.

You write your code and compile it all with webpack into a single file, all you have to do is write two manifest files which are 70% the same.

There are some incompatibilities between v2 and v3, like v3 having promises for the extension api. I wrote wrappers for the non-promise versions myself (I'm sure there are packages that do this for you). Webpack takes care of a lot of the other inconsistencies like module support.

Also note that you should 100% make sure that you follow the guidelines for how to structure a plugin for the v3 version, ie that it is event based. Your background scripts will be shut down randomly every now and then and you will get insanely buggy code when running in v3 if you don't follow the guidelines strictly.

For now, I just ship v2 to both firefox and chrome, it's easiest for me. Note though I have had this plugin for a couple years now, maybe it's not possible to create _new_ plugins with v2.

Yeah there has been a recent change: “As of January 17, 2022 Chrome Web Store has stopped accepting new Manifest V2 extensions. We strongly recommend that new extensions target Manifest V3.”[0]

I guess I made the mistake of developing for Firefox first with their documentation/guides. I am using rollup and the polyfill plugin per some suggestions, but it certainly isn’t generating anything compatible for v3, and I believe it breaks on the background script vs. worker thing.

[0] https://developer.chrome.com/docs/extensions/mv2/

Urgh, not accepting new V2 extensions is terrible, I didn't realise they'd done that.

Up until now I've just been publishing the exact same extension for Firefox/Chrome/Edge (and also as a user script), as Firefox supports using the global `chrome` object for everything I've needed it for. The only browser-specific stuff has been targeting different browsers with CSS in the options page to make it blend in with the default light and dark mode themes in Firefox/Chrome/Edge.

Looks like I'm in the same boat the next time I need a new extension.

Oh that's sad.

Only good thing about this is that Mozilla is working on v3 support.

> Manifest v3 is a large platform project, and some parts of it will take longer than others to implement. As of this writing, we are hoping to complete enough work on this project to support developer testing in Q4 2021 and *start accepting v3 submissions in early 2022.* This schedule may be pushed back or delayed due to unforeseeable circumstances.

Unfortunately, this article was written in May 2021. As far as I can see there's no update to this article yet, so we don't know what "early" 2022 means.

> https://blog.mozilla.org/addons/2021/05/27/manifest-v3-updat...

> Existing Manifest V2 extensions that have previously been published publicly will not be affected by this change and updates to those already-published extensions will continue to be accepted.

Source: email dated 2021-12-12

Chrome won't run V2 extensions in less than a year from now:

https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

Hey, Simeon from the Chrome Extensions team here. A lot of other replies talk about libraries and tools; I'd like to focus more on some general guidance.

First up, no, you don't need to maintain two completely different code bases. I'd recommend having a separate manifest.json for each browser or having a build step generate the per-browser manifest.json. A lot of the manifest changes are relatively small, like splitting "host_permissions" out from "permissions" and should be automatable. For example, a build step would merge these two arrays for the MV2 manifest.

As for your background scripts, if possible I'd recommend limiting the JS capabilities you use to the intersection of what all browsers support.

- Chrome supports background service workers - Safari supports event pages and I believe has service worker support in beta builds of their OSs - Firefox supports persistent background pages

In other words, target the capabilities available in both worker and page contexts. You'll also want to design your background logic to embrace ephemerality. This is required by Chrome, but it also benefits Firefox users in that it helps keep the browser responsive.

Best of luck!

Hi Simeon, I appreciate your engagement on this. I suppose I am being dramatic in wording it as a "separate codebase", and yes, one can generate two separate manifest.json files. My end-result has been to have separate code for Chrome and Firefox, though, because the polyfill doesn't work as advertised and as you've noted, there are certain things that are not compatible across different browsers.

It isn't a horrible workaround, but I will need to update code in two places every time I want to make a change, and that is bad developer experience, bad for timely updates, bad for being able to support a user regardless of the browser they use. I don't care what they use, I just want them to be able to use my tool. But as far as I can tell, the whole ecosystem for developing and publishing browser extensions is quite behind, at least as compared to the rest of the things I work on.

I appreciate your general guidance, and accept that this simply isn't the best state of things to work with.

I made ExtensionPay[1] (a service to help you take payments in extensions) and I used Mozilla's `browser` shim in the extension library itself. MV3 is not available on Firefox yet so I support both MV2 and MV3, but yeah it's a pain in the butt to have one MV2 version and one MV3 version.

[1] https://extensionpay.com

For our browser extension, The Camelizer, I wrote Spader: https://github.com/cosmic-shovel/spader

It lets me use Ruby in my html/css/js files, and also sass in the css, letting us use one codebase for all target browsers.

Definitely a work in progress, and lacks the exciting auto-reload functionality of other similar projects, but it works for us. Issuing one build command and having an extension for all our target browsers is pretty nice.

I ended up writing a build script that makes the required changes for chrome/ff extension.

This will become harder when mv3 gets pushed out broadly, but it's def not pretty :(

I just wrote my first extensions for a new side project (https://getbirdfeeder.com) a few weeks ago. Initially I thought that now after a few years everything will be mostly standardized with "web extensions" and I just upload the extension to the three big extension stores. Turns out it's nothing like that and I wrote a little bit about my misconceptions in my blog [1]. It's still not a great development workflow. If there's any good strategies I'll gladly give that a try.

My initial plan to have a private package that I just import in my extensions but turns out you can't really do that as imports don't work. Right now I'm kinda stuck in copy pasting code back and fort hand keeping a V2 Extension for Firefox (and Safari) and a V3 Extension for Chrome. I also keep separate manifest files as they have different features.

[1] https://blog.notmyhostna.me/posts/building-web-extensions-fo...

I worked with extensions for roughly 4 years on a handful of separate projects. I had managed a framework which abstracted over all APIs (including the insane old Safari one).

While I can't share the framework, I have designed a code base architecture which allows incremental abstraction of APIs, uses typed message passing between scripts (with errors being propagated too), unit and integration tests or automation for compilation of the extension for each store according to their respective rules. This architecture is my IP and although I don't actively work with extensions on day to day basis anymore, I still do take on contracts to lay foundations or migrate existing projects.

If this is something you're interested in, reach out to me via email in my bio.

Could anyone suggest a good resources/guides/tutorials/books for writing Firefox add-ons?

I remember making a cursory search a year ago, and hardly found anything remarkable. (Might have been a case of Google's-bad-search-results syndrome.)

MDN is what I've used in the past:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

https://github.com/mdn/webextensions-examples

Oddly enough, MDN is a far superior resource for manifest V3 than Google's own documentation.

This is really odd because Firefox doesn't even have a manifest V3 implementation yet.

Anyway, to answer your question, MDN is for sure the place to go.

Since this thread is full of Browser-extension creator. I have a related question: How do you make money with Browser-Extension (without selling data)?

We charge a subscription fee of a couple dollars per month. We've been approached by data brokers and the like, but that's not our style.

We once did a lifetime subscription event in conjunction with StackSocial. It was worth it, but not amazingly so.

> Chrome recently mandated that only manifest V3 extensions can be submit to their online store

Can someone provide a source for this please?

My company has an extension with the old manifest V1 and I'd like to propose upgrading or getting rid of the extension all together.

Update: here is the source https://developer.chrome.com/blog/mv2-transition/

Also interesting, how do you monetize? (Besides acquiring a lot of users and selling out)

Does anyone know how Brave will handle manifest V3?

Brave's ad-blocker is not an extension, it is natively implemented, so the Brave will stay unaffected.

Yeah, I'm an extension developer and wondering if I'll be able to point users toward Brave if they want to keep using our V2 version.

A product manager from Brave once said this:

See: https://www.reddit.com/r/brave_browser/comments/rdab12/comme...

I gave up and deleted my plug-in for Chrome.