Browser Extensions Standard
browserext.github.io
browserext.github.io
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.
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)
Consider WebExtensions Experiments: https://webextensions-experiments.readthedocs.io/en/latest/w...
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.
The vendors are using both terms. See, for example, the text at the end of this url, and both terms in the text.
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.
Browsers can add their own brand new features, the specs are just for the minimum.
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.
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).
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?
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)
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?
Just because Microsoft is more anti-competitive than Google does not change anything I said
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.
[0] : https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...
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.
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.
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.
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.
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...
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.
0. https://bugzilla.mozilla.org/show_bug.cgi?id=1384515#a545216...
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.
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.
Also, I know it's possible to run third-party extensions in developer mode.
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.
I can't wait to port my extension to Firefox. Firefox is seeming like a more and more viable option to Chrome.
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.
That's actually the main reason for which Firefox is moving away from XUL add-ons and towards more restricted WebExtensions.
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.
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]
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.
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.
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?)
Well, that and it was Google.com's "chrome".
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!
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.
Do you mean Chrome supports Promises like Firefox does? Last time I checked, the Chrome APIs were using callbacks for all asynchronous operations.
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...
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.
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.
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.
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.
[1] https://news.ycombinator.com/item?id=14888010 (just 2 days ago!)
(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)
So how does this change anything?
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.
I just don't see how any of that is relevant to the original comment I replied to:
> But will Google allow this to happen, as it would strip them a huge selling point for Chrome?
In what way would standardizing WebExtensions, which are already supported by all modern browsers (sans Safari), strip Chrome of selling points?
Why should Google have to "allow" this?
Standardized WebExtensions dilute that, because they allow easy ports to the other browsers.
Mozilla and Microsoft are specifically re-implementing the Chrome Extensions API, and documenting it.
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.