Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters?
This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of.
Having it be a standard adds security but strictly limits extensions to things the browser vendors explicitly did conceive of, and stamped their approval on -- sometimes literally, if you're going through a curated store. Is that a net win? I'm not sure.
> Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters?
The main difference is that the user installs an extension, which possibly modifies the behavior of the browser for all websites. A traditional web API only takes effect if the page that the user visits makes use of that API.
> if web extensions become a standard, are they really even extensions?
They're browser extensions, not web extensions. If standardised, then arguably they will be a native part of the web stack, yes.
> strictly limits extensions to things the browser vendors explicitly did conceive of, and stamped their approval on
That's the situation today anyway. The new standard won't change that. Browser vendors may opt to follow the new extensions standard as a 'baseline' feature set, and provide further non-standard options on top of it.
Most extension APIs follow common patterns, and this standard paves those cowpaths. The standard needn't predict all future extension needs to be useful today. For comparison, the DOM is a standard, but individual browser vendors still experiment with their own custom DOM features, and these experiments sometimes get 'merged in' to the standard. Meanwhile, authors benefit from having a well defined set of features that work across platforms. Standardisation doesn't need to be final or absolute to be useful.
While I as a developer greatly appreciate creating things with the new WebExtensions APIs over old Firefox XUL thingies, I can see how they severely limit my capabilities. If the browser says "You can't do that", I can't do that.
And based on that, you don't have to look too hard into the Firefox userbase to find out that quite a lot people have an answer for your question: "No"
(Background: Firefox is going WebExtensions only in a near upcoming release. Not everyone is thrilled about that)
In general, if your software supports plugins, you can:
1. Have plugins with ultimate power (meaning that plugins can change everything, no encapsulation)
2. Stable API/ABI (meaning that plugins written for version 1 will work with version 2)
3. A refactorable code base.
You can pick only two out of three.
Traditionally, Firefox chose 1 and 2, and for stuck without multiprocess support for years (causing it to have worse performance and security), and now wants to move to 2 and 3.
Incidentally, I suspect that's _one_ of the reasons Linux doesn't have a stable Kernel ABI - they chose 1 and 3.
There is one plausible solution to this inequality: the Unix philosophy. Small parts, loosely coupled. Individual parts can't be significantly changed or removed, but they can be deprecated and better alternatives added. Because the parts themselves are small, they're less likely to have errors and replacing them is cheap.
Rich Hickey also has a talk on this. And there's also an overlap with CRDTs (basically you have a distributed system unless you can refactor everything atomically).
Firefox tries to minimize breaking API changes, but there have certainly been plenty of them. While avoiding API changes presumably made the switch to multiprocessing more difficult, it didn't stop it; they made the switch. The fundamental problem with extensions and multiprocessing (at least from the perception of someone who wrote FF extensions) is the obvious one: Rather than having everything for all windows in a single thread, now you have them in different processes; communication goes from literally nothing to IPC.
That's a common set of features every browser should support. Because doesn't make sense to have various techniques to achieve simple behaviors like a toolbar button.
Browsers can add their own brand new features, the specs are just for the minimum.
Another perspective would be that a standardized browser extension api means you're not locked into browsers via "essential" extensions. Though, while I do like removing locking, I'm not sure if that is a bigger concern than what you cite.
Finally! WebExtensions (https://developer.mozilla.org/en-US/Add-ons/WebExtensions) have slowly been becoming an adhoc standard for a little while now, but with a few tricky small differences here and there between browsers (e.g. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Ch...). So far it's just been Firefox and Edge slowly building a close approximation of Chrome's existing API, but a proper standard for this would be great, and make it much clearer what extension developers can _depend_ on, and what's optional.
Right now you basically write your extension once (probably for Chrome), and then port it to the others, often with various small manual changes or workarounds for incompatibilities. It's much better than it used to be, but still pretty inconvenient and error prone.
I can see at least a couple of differences with current implementations though, like using the `browserext://` protocol instead of `moz-extension://` and `chrome-extension://`. Does anybody more involved with this have a summary of the differences between this spec and Firefox, Edge and Chrome's implementations?
Yes, Finally, all browser will be chrome clones, just what we need...
Sad times indeed, when people celebrate mono-culture and the lack of options...
W3C is leading effort to kill the Open Web and everyone is just clapping long... EME, Browser Extensions, what will be the next thing W3C will sell to its google overlords?
This is wild overreaction. Google is by far the market leader, they pump out innovations in this space, and their decision to work with others mimicing its APIs so that browser extensions can have a level of cross-compatibility is is perfectly nice and pro-competition as you could possibly ask for. I guarantee you if Edge had such a flourishing browser extension marketplace Microsoft would do everything in its power to prevent the other browsers from allowing easy portability.
Yet the actual effect is that the Firefox' browser extension marketplace is severely reduced (by their own descision, admittedly) while Chromes' stays the same for the time being.
I'm not very involved, but on top of the Chrome base API both Firefox and Edge have a bunch of additional APIs IIRC (I think Firefox supports all of the Chrome APIs but I'm not sure). The intent is to have the same manifest format so basic extensions work everywhere, but extensions can use browser-specific APIs that fit within the same general framework too.
> I think Firefox supports all of the Chrome APIs but I'm not sure
They support quite a few but not all. in addition there is a promise based version of each of the APIs that you can use in firefox under the browser namespace instead of the chrome namespace. (with a polyfill on npm too if you want that in chrome)
The only problem which Mozilla didn't think about or hasn't given much value to is the huge number of add-ons that are going to die or just stop working when they completely switch to WebExtensions (as there's just no replacement to the previous API in them). One of the Firefox's USPs was its addons which could modify the browser behavior and UI in any manner. It's all going to go, and Mozilla is moving closer to becoming a Chrome clone (albeit open).
For example, a hugely useful feature for me was TabGroups (Panorama) which they removed from the main browser to make it an external add-on, and even that will stop working soon [0].
Similarly, there are add-ons which modify the browser's inbuilt 'Find in page' behavior in Firefox. Looks like even they are not WebExtension compatible.
Mozilla has given this a lot of thought, and realized it is extremely valuable. But the value does not dwarf the downsides.
XUL extensions would block most of the Servo work, as an obvious example. You can't rely on the browser internals if those are changing underneath you.
Had they given it enough thought, they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way, for example. But they found killing all of the valuable add-ons of years worth of work of so many developers justified.
> they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way
Which "they" did, and are. Some APIs are more amenable to such replacement than others. For example, APIs that allow you to modify any part of the browser UI in an arbitrary way are not so amenable _and_ have the problem of breaking any time the internal structure of the UI changes. Which has, in the past, prevented improvements to the internal structure of the UI...
It's really easy to see only one side of this (the downside of extensions breaking, or the upside of not having your implementation severely constrained by extensions that keep depending on internal details they shouldn't depend on). But there are in fact people who've thought long and hard about both sides of this.
Except the downsides are mostly for the users (extensions stop working) while the upsides are mostly for the browser developers. (Better ability to refactor and update)
The upsides are for users as well: better performance, less memory usage, better ability to implement web standards. Browser developers aren't just breaking extensions for the fun of it, but because they're in the way of actually producing a better product; the goal is to produce said better product.
The upsides are just somewhat more diffuse than the downsides: the former apply to all users, while the latter only to those who have extensions that stop working.
The thing is, I as an end user shouldn't need to look from both sides (where one side is predominantly of the FF developers or extension developers). I speak for my continued convenience of using Firefox as a browser which had an upper hand to Chrome to Chrome due to its extensions (as far as I'm concerned) which will end soon.
As end users, many (in fact a majority) have already made the decision that the benefits of Firefox's extensions don't outweigh the drawbacks those same extensions impose on Firefox in terms of performance and responsiveness, and have voted with their feet.
I appreciate that your personal tradeoff was different from most, and I know the pain of having an application that was targeting your use cases move away from that. I don't have much to offer other than the goal that Firefox still has to offer extension APIs that are broader than the ones Chrome does. It won't be quite as "yeah, hook into anything you want" as the old extension system, but that was really becoming completely unsustainable and was holding back Firefox not only in things like performance and responsiveness but also web standards: extensions would depend on things working a certain way and changing them to follow the spec would break those extensions...
I find unfortunate to see such trivialization of dev work from outside. They had to deal with years of legacy code piling up, and this was seriously impeding the modernization of Firefox.
Had they given it enough thought, they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way...
They have. It is not finished yet but work is underway.
I also learnes from last(?) discussion about Firefox here on HN that there is even a developer extension that you can install on nightly that will let you create your own extension api.
This is useful 1. if you are a developer that is happy with using nightly and making/copying extensions on top of your own api 2. even more useful as you can sketch out api ideas in js without touching the Firefox C++ codebase.
BTW: Manishearth who is acrive in this discussion often shares knowledge from the inside of Mozilla. If anyone are really interested then reading his comment history might be interesting.
It makes use of the new Containers experiment to provide a similar tab organization mechanism as TabGroups, and presents them in a vertical sidebar which IMO makes for a much saner workflow for heavier tab users. The identity encapsulation that comes by default with Containers might not be what you're looking for in a pure tab management system though, but as Sea Containers shows, some variant of tab grouping can definitely be implemented in WebExtensions.
Though Containers are mutually separate in terms of the cookies etc. (they're more like the good old 'Profiles' that I still use for keeping my 'work', 'personal' and 'dev' work separate) this still looks interesting. Thanks.
As a developer, I'd really like if I could publish an extension as a single archive file and have users load it into whatever (compliant) browser they like - however, the standard doesn't seem to actually support this. When it comes to packaging, there is nothing more than a vague acknowledgment:
Browser extensions MAY be distributed and subsequently loaded as individual files or via a container, such as a .zip archive. Regardless of the packaging format, these containers MUST contain the following: [manifest.json, Necessary JavaScript files (<filename>.js)] [...]
Browser vendors MAY require that extension packages include a digital signature. The signature MAY indicate the source of the extension, such as a distribution store or the extension's publisher. This aspect of packaging varies by browser, and browser implementers MAY enforce different requirements.
I guess that's a concesson to all the politics surrounding app stores, but it's disappointing nevertheless.
A standard package format would be nice, but this looks like enough to let developers publish once and have their build tooling do most of the work of packaging for different targets.
As a chrome extension developer I really like this. Previously I didn't develop extensions for other browsers because I would have to learn another ecosystem. Now it could be pretty simple to do.
I also like that all of the asynchronous API calls are returning Promises. Chrome API is still using callbacks. This also means that some time will pass while this is even added to chrome. I expect that there will be a polyfill library that translates the new API calls to legacy browser API calls.
Sorry for not bringing anything of value to the discussion but: Heck. Yes! I love Firefox for going in this direction. The politics of embracing Chrome's extension APIs and standardising upon them must have been astounding.
I can't wait to port my extension to Firefox. Firefox is seeming like a more and more viable option to Chrome.
It would be interesting to have a browser where every part except the engine is an extension. I.e. hotkeys, address field, bookmarks and so on being standardized, replaceble extensions, run in a chromeless window. An infinitely hackable experience. Prepackaged bundles could ship as discreet browsers, for the less techy user.
Well, that sounds like the historical Firefox. If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on. Worked like a charm for the first 10 years, not so much afterwards because it became a maintenance nightmare.
That's actually the main reason for which Firefox is moving away from XUL add-ons and towards more restricted WebExtensions.
> If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on
That's not really true at all. Most of the Firefox UI was written in JS (and XUL and XBL), but not as add-ons.
It would have been great if it were true, because not only do you get the reconfigurability the parent commenter writes about, but there are even better advantages: it would also have meant the Firefox team themselves would have had to confront the poor APIs exposed to extension authors and the poor practices about breaking things. The reality is everyone just touched browser.js (or what have you) to make it do what they wanted.† Had that not been the case, the deprecation of old-style toolkit add-ons might have happened long ago and a good replacement created. What happened instead is the worst from both ends: a sickly add-ons ecosystem built on top of fragile XUL-based extensions hobbled along for years, and now that they are obsoleted, they are given a replacement that is decidedly not good.
When Robcee announced he'd gotten the imprimatur to ship devtools with Firefox, I made an impassioned plea for it to be developed and shipped it as a built-in add-on, for exactly these reasons, and because it would have allowed faster development iteration and provided an easier contribution path (no need to ever waste hours rebuilding nightly, or asking for the same from a casual contributor who wants to submit a patch but doesn't work for a manager with an @mozilla.com address). No dice.
† Not to mention tons of XPCOM junk not related to rendering or parsing or the JS runtime that was nevertheless implemented in C++ and would need updates to the core if ever wanting to anything non-trivial.
That sounds like a dream in many respects, but also, by analogy with the size of laptops where every part is customiseable and swappable, like it could be very, very slow or crash-prone. Much of the bugginess of Windows comes from its need to accommodate all possible combinations of bizarre hardware offerings; and much of the "It Just Works" of (some) Apple products comes from the tightly integrated nature of their technology stacks.
I don't really agree with that analogy. Dealing with hardware versus software is vastly different. Demanding driver updates from manufacturers, and then enforcing them onto users is real messy compared to changing an API (with reasonable heads up) and expecting extension developers to adhere or become incompatible.
> Dealing with hardware versus software is vastly different.
I agree; it's important not to read too much (which may be anything!) into the analogy. I just meant that there's a trade-off between flexibility and optimisation, and mentioned the first example of that trade-off that came to mind.
Isn't the problem with Electron that any app built with it spawns a full browser runtime? Doesn't seem to be a problem if the app in question is in fact a browser. More like a necessity really.
One problem with this is that if extensions need to be sandboxed from the user, the browser, and each other. Therefore you'r proposing running a process for each part of the browser.
Does anybody know whether the Google Chrome / Chromium team and the Mozilla team are squarely behind this standardization effort? What about the Apple Safari team?
There's only one rep from Google in the community group. There don't seem to be any from Apple.
[1990s paranoia mode] this could be another Microsoft effort to embrace and suffocate [/1990s paranoia mode]
They've been looking to replace the current extension model for years, as it's not even really an API, it's mostly just a way for people to fuck around with Firefox's source code. Powerful, but unwieldy and extensions break all the time, if Mozilla changes anything.
Well, and one idea in that process was to not write a new extension API from scratch, but rather use the proven API from Chrome, which therefore will also make the transition much less painful, as a good portion of Chrome extensions will get ported over and we're not starting at square one with the extension ecosystem.
Also, they recently introduced multi-process which breaks all extensions anyways, so they're pushing hard to get WebExtensions done, as it means that add-on authors can just port directly to WebExtensions and don't have to port to multi-process-compatible first.
And if Chrome continues to eat up market share and extension developers lose interest in Firefox, this will also help out, as the effort of porting from Chrome to Firefox is now often trivial.
So, yeah, Firefox 57 will exclusively run WebExtensions, which is Nov 14.
Microsoft mostly just saw what Mozilla is doing, figured that they still needed an extension system to get Edge fit for competition and figured that complying to the standard for once would get their extension ecosystem quicker up to speed.
As for Google, well, I assume they are not particularly excited about Mozilla embracing and extending their extension API, as well as Microsoft having a slice from their cake, too, but it's not like Chrome was in any danger of competition...
I've been working on web extensions for multiple browsers lately.
Chrome and Firefox have workable ecosystems and accept more or less the same code, but package it differently.
Edge accepts almost the same code, but they had to change the "chrome" namespace to "browser". I suppose it was a question of pride. Also, Edge doesn't have a workable way to publish and to inline-install web extensions.
Safari accepts similar code to the rest, but organized differently. They have a slow and ponderous process for approving extensions for their store. They don't offer anything remotely resembling inline installation.
> but they had to change the "chrome" namespace to "browser"
It's weird, because Firefox internally has had the "chrome" namespace long before Google Chrome existed.
In browser terminology the browser "chrome" is the stuff that's outside the browser engine -- the stuff that doesn't handle loading/laying out/rendering/javascripting a page. I.e. the tab strip, URL bar, bookmarks, context menus, settings, etc.
IIRC (very unsure of this, but have heard it from different non-google sources) the name "Google Chrome" is actually a joke on this because it had the least chrome amongst browsers of the time (remember the toolbar and status bar?)
> IIRC (very unsure of this, but have heard it from different non-google sources) the name "Google Chrome" is actually a joke on this because it had the least chrome amongst browsers of the time (remember the toolbar and status bar?)
Safari has a different API that is also very limited compared to Chrome/FF.
I recently tried to port my Chrome extension to Safari (which I actually use as my main browser) and failed because of the lack of many necessary calls like a check for idle or if the app is in focus.
I wrote it for Firefox, and then I wondered what it would take to port it to Chrome. The answer was "nothing really" - it worked out of the box for the main functionality. I had to do a small wrapper over loading settings, but having done a million extensions in the past, I was pretty surprised to see it load straight into a different browser!
That's because Firefox's new WebExtensions API is based off Chrome's, not because of any formal standard.
This standard seems to be intended to formalize a lot of the stuff Chrome does so that other browsers can follow a common _standard_ instead of just being stuck imitating what Chrome does.
Safari is moving away from the 'pure JS, in-browser-process' extension mechanism entirely and I doubt the Chrome people are prepared to be saddled with a standards process for their own API they are still actively developing. As a practical matter, this standard/group seem rather pointless.
Part of the reason why we have different browsers is the variety of features they support. A browser extension inherently is closer to the unique part of browsers that make them different.
What value does this really provide? The times that I've gotten into browser extensions were really working with features that are unique to the given browser.
There's an argument that while rendering engines are huge, monolithic undertakings, the actual browsers wrapped around them are fairly trivial. Assuming they use the same rendering engine under the hood, a relatively lightweight, tightly integrated platform-native browser (i.e. Safari or Gnome Web) might be a better user experience than a cross-platform behemoth like Chrome.
Extension support and depth of extension library have traditionally been the big pain point with switching to a minority browser. Moving extension support into a browser independent standard removes a lot of the selective pressure toward a monoculture.
Well, the APIs that make sense for various browsers can be shared by those browsers. The APIs that are specific won't be.
For example, Chrome doesn't support sidebars. Opera does. So, Opera constructed a sidebar API. Then came along Mozilla, also wanted to have sidebar, and so they adopted Opera's sidebar API, allowing extension authors to easily support Firefox and Opera.
They can't support Chrome, but it's not like people didn't previously already write sidebar extensions when they could only support one browser at a time.
It would be really nice if you could blacklist websites from using extensions in Safari, e.g. banking websites.
There are lots of useful extensions out there that would be nice to use, but I'm concerned if they became compromised (which happens regularly[1]) they might hijack my data.
Safari has a great feature that stops extensions from being able to read or transmit anything from websites you visit, which is great, but limits the effectiveness of a lot of ad blockers.
The add-on ecosystem of Chrome currently dwarfs Firefoxes. Firefox extensions used to be more capable, but there's just more and certainly more NEW ones for Chrome.
(I'm sure this was an important consideration for Mozilla as well - it reduced the supposed value of their "more powerful" XUL extension system, as in practice you can often find a Chrome extension to do what you want, but not a Firefox one)
But it can't keep XUL compatibility and do major overhauls of the browser.
If XUL compatibility doesn't even get you a clear advantage in the add-ons area, should it block modernizing the browser?
Firefox can't be the browser that people use only because they're stuck on it because they have extensions that changes how the browser works. Think about that for a bit.
WebExtensions are already supported by Firefox and Edge. Today.
Hard to believe, but extensions are standardizing without any real standardization body, just kind of... on their own. This is just a formalization of that.
Not sure what you mean by this, but this (like most modern web standards, and I'm not even sure of the modern part) is just documenting what the implementations are already doing.
Mozilla and Microsoft are specifically re-implementing the Chrome Extensions API, and documenting it.
This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of.
Having it be a standard adds security but strictly limits extensions to things the browser vendors explicitly did conceive of, and stamped their approval on -- sometimes literally, if you're going through a curated store. Is that a net win? I'm not sure.