Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters?<p>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.<p>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.
Finally! WebExtensions (<a href="https://developer.mozilla.org/en-US/Add-ons/WebExtensions" rel="nofollow">https://developer.mozilla.org/en-US/Add-ons/WebExtensions</a>) 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. <a href="https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities" rel="nofollow">https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Ch...</a>). 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.<p>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.<p>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?
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).<p>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.<p>[0] : <a href="https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/" rel="nofollow">https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...</a>
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:<p><i>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)] [...]<p>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><p>I guess that's a concesson to all the politics surrounding app stores, but it's disappointing nevertheless.
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.<p>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.<p>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.
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?<p>There's only one rep from Google in the community group. There don't seem to be any from Apple.<p>[1990s paranoia mode] this could be another Microsoft effort to embrace and suffocate [/1990s paranoia mode]
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.<p>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.
It would be really nice if you could blacklist websites from using extensions in Safari, e.g. banking websites.<p>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.<p>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.<p>[1] <a href="https://news.ycombinator.com/item?id=14888010" rel="nofollow">https://news.ycombinator.com/item?id=14888010</a> (just 2 days ago!)