How do you avoid repeating code for, say, both a Firefox and Chrome extension? Chrome recently mandated that only manifest V3 extensions can be submit to their online store, and that introduces quite the number of breaking changes from V2 (even with the polyfill package). As far as I can tell, Firefox does not yet support V3 (I could be quite mistaken there).<p>As someone new to writing extensions and trying to write something for at least both Firefox and Chrome, how should I go about it? Or do I have to accept writing separate background.js files, separate manifest.json files, etc.?
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.<p>So maybe you can just wait? Although it may take a long time.<p>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.<p>[0] <a href="https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/" rel="nofollow">https://blog.mozilla.org/addons/2021/05/27/manifest-v3-updat...</a>
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.<p>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.<p>[0] <a href="https://github.com/mozilla/webextension-polyfill/" rel="nofollow">https://github.com/mozilla/webextension-polyfill/</a><p>[1] <a href="https://github.com/webpack/docs/wiki/list-of-plugins#defineplugin" rel="nofollow">https://github.com/webpack/docs/wiki/list-of-plugins#definep...</a>
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.<p>[0] <a href="https://quasar.dev/quasar-cli/developing-browser-extensions/introduction" rel="nofollow">https://quasar.dev/quasar-cli/developing-browser-extensions/...</a>
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.
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).
Unless something changed in the past 3 weeks, you can still upload manifest V2 plugins to chrome, I uploaded one a few weeks ago.<p>Otherwise, what I did to support v2 for firefox and v3 for chrome is fairly straightforward.<p>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.<p>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.<p>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.<p>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.
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.<p>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.<p>As for your background scripts, if possible I'd recommend limiting the JS capabilities you use to the intersection of what all browsers support.<p>- 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<p>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.<p>Best of luck!
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.<p>[1] <a href="https://extensionpay.com" rel="nofollow">https://extensionpay.com</a>
For our browser extension, The Camelizer, I wrote Spader: <a href="https://github.com/cosmic-shovel/spader" rel="nofollow">https://github.com/cosmic-shovel/spader</a><p>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.<p>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.<p>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 (<a href="https://getbirdfeeder.com" rel="nofollow">https://getbirdfeeder.com</a>) 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.<p>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.<p>[1] <a href="https://blog.notmyhostna.me/posts/building-web-extensions-for-chrome-firefox-and-safari/" rel="nofollow">https://blog.notmyhostna.me/posts/building-web-extensions-fo...</a>
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).<p>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.<p>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?<p>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.)
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)?
> Chrome recently mandated that only manifest V3 extensions can be submit to their online store<p>Can someone provide a source for this please?<p>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.