Firefox users may import Chrome extensions now
ghacks.net
ghacks.net
You can generally have a common background.js file, maybe with a few conditionals, but the manifest.json file needs to be different for Chrome and Firefox.
I decided to keep two foo-manifest.json versions in a manifest/ subdirectory, and copy one to ../manifest.json depending on which browser I'm testing. It's a bit tedious. Not sure if a better solution exists.
It's a work in progress: https://bugzilla.mozilla.org/show_bug.cgi?id=1609923
> I decided to keep two foo-manifest.json versions in a manifest/ subdirectory, and copy one to ../manifest.json depending on which browser I'm testing. It's a bit tedious. Not sure if a better solution exists.
Personally, I favor having a build step that produces the final manifest. The basic idea is that you have a common manifest.json + paired down browser-specific files that override the general settings as necessary. It's not a perfect solution, but I think it makes maintenance a bit easier.
A bit off topic, but as a co-chair of the WebExtensions Community Group[1] (WECG) I'm a bit touchy about the calling WebExtensions "standardized." A few years back the Browser Extensions Community Group[2] created a spec for WebExtensions, but it never reached a state that we'd normally refer to as a web standard. (Technically W3C community groups can only produce "Reports" and these documents are not on the standards track.[3])
FWIW, I'm very bullish about specifying and (hopefully) standardizing the WebExtensions platform. I'm especially excited about having a good chunk of dedicated time to sit with browser folks at TPAC 2023[4] and try to work out some open questions about where we're going and how we're going to get there.
[1]: https://github.com/w3c/webextensions/ [2]: https://browserext.github.io/ [3]: https://www.w3.org/community/about/faq/ [4]: https://www.w3.org/2023/09/TPAC/
On a purely technical level, I think it should be possible to write some sort of "emulation layer" that exposes a Chrome-flavored WebExtension sandbox and translates the calls to the respective Firefox APIs wherever possible.
However once that functionality exists, where would you actually get those extensions from and how would you install them? Firefox famously doesn't allow extensions to be installed that are not registered with the Mozilla's store, and Chrome extensions obviously aren't. Even if they relaxed that rule, you'd also expect automatic updating to work, just like for "native" Firefox extensions.
So in effect, Firefox would have to integrate Chrome's store as a second legitimate extension repository. That would be a boon for users, but I can think of reasons while neither Mozilla nor Google would want to do this:
For Mozilla, it would mean loss of control over half of the extension ecosystem: They cannot ban Chrome extensions, they have no control over their approval process etc, but now users could install them and receive continuous updates - sonin effect, Google would suddenly be able to push updates to Firefox installations.
On the other hand, Google would lose its moat around the extension store: Everything that Chrome offers would now be automatically supported by Firefox as well.
So I think, neither would Mozilla want to include Chrome's store in Firefox, nor would Google allow that.
Normally when browser folk talk about "cross-browser extensions," we're not focusing on the distributable package so much as the source code. As you suggest, there are a variety of reasons that browsers aren't terribly interested in having a single authoritative distribution channel. For that matter, the packaging format is explicitly not something we intended to discuss in the WebExtensions Community Group[1]. While we diversity in how extensions are marketed and distributed, we want the actual code of the extensions to be as reusable as (reasonably) possible.
Have things changed?
Why wait? Change now. If you do the tech support for your parents, change theirs. It's a web browser, not vim vs emacs. There's little to no friction in changing.
"Mozilla decided to create a list of extension pairs for extensions that are available on the Chrome Web Store and the Mozilla Add-ons Store. Instead of importing the Chrome extension directly, Firefox is installing the Firefox version of the extension from Mozilla's own extension store."
So far they have 73 pairs, but should increase overtime and likely cover the most commonly used extensions.
None of these browsers that advertise this work with devtools extensions from Chrome. React, Vue, and Alpine devtools are all dead in the water. Luckily the big ones have native builds for Firefox, but none of the Safari based browsers (like Orion) can run Chrome based devtools despite advertising "works with Chrome extensions!"
I hope one day they get there, but for now, I need to use a Chromium browser to effectively debug some applications, and that's a bummer.
(Yes, I know many of these tools offer a standalone build that can connect via websockets, but ime, they are unreliable or a pain to setup.)