It's still using Firefox extensions, this is for people switching from Chrome to Firefox (or those who want to use both browsers with the same extensions.) From the article:
"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.
The problem with all of these cross browser extension translation layers, is that they only work on the most superficial level for ultra simple 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.)
I was underwhelmed to discover that this is simply a list of extensions (currently at 73) that exist in both the Chrome Web Store and Firefox Addons and not some sort of cross-platform support.
One of the main purposes was to make developers lives easier so you can have a single codebase instead of juggling with browser specific APIs and configs. Otherwise many developers would just go with a market default.
The biggest problem I found is that Chrome Manifest V3 requires background.service_worker (they removed background.scripts), while Firefox Manifest V3 requires background.scripts (they never implemented background.service_worker)
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.
> The biggest problem I found is that Chrome Manifest V3 requires background.service_worker (they removed background.scripts), while Firefox Manifest V3 requires background.scripts (they never implemented background.service_worker)
> 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.
Kind of getting off topic here but if Web Environment Integrity takes off then the whole issue is that its then up to the website if you're even allowed to use Firefox.
I'm not sure... Are you saying Firefox is the only ADA compliant browser? Years ago when I dealt with ADA and web accessibility I found gaps across all the browsers. There wasn't a one-size fits all. Rather mileage varied with each website.
I don't mean to be a dick but people giving Chrome its marketshare is the reason why Google is confident in rolling out dystopian changes.
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.
Though this isn’t actually about importing extensions that aren’t already in Firefox, the extension APIs are standardised enough that this is actually possible a lot of the time. For example, I unpacked the Google Translate extension, made a single change to the manifest (I think so Firefox recognises it as supported) and loaded it into Firefox and it works perfectly! But it doesn’t work for everything, Amazon’s Send To Kindle extension didn’t work for me. It would be nice if there was an automated way to do this, I think there used to be. Maybe I can try to make something
> the extension APIs are standardised enough that this is actually possible a lot of the time
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.
Title is false. I'm not even going to say misleading. No there isn't a compatibility layer for Chrome extensions to run in Firefox. There's just a list of extensions that are available in both browsers.
I wonder if the main obstacle to (actual) cross-browser extensions isn't so much technical but rather political.
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.
> I wonder if the main obstacle to (actual) cross-browser extensions isn't so much technical but rather political.
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.
29 comments
[ 2.7 ms ] story [ 92.1 ms ] thread"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.)
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.
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.
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.
[1]: https://github.com/w3c/webextensions/