9 ms·

Browser Extensions Standard

206 points by tbassetto 9y ago

pimterry 9y ago
Finally! WebExtensions (https://developer.mozilla.org/en-US/Add-ons/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/Chrome_incompatibilities 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?
- Manishearth 9y ago
  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.
  - kbrosnan 9y ago
    One of the big differences is that Firefox and Edge do not support any of the deprecated APIs.
  - weaksauce 9y ago
    > 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)
- syshum 9y ago
  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?
  - pzone 9y ago
    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.
    - syshum 9y ago
      Pointing to another company and saying "Well they would be more evil" is not IMO a valid defense. Just because Microsoft is more anti-competitive than Google does not change anything I said
    - xg15 9y ago
      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.
fibo 9y ago
Looks a really good idea
Nyrox 9y ago
Cute idea, but I will eat a broom before this actually becomes reality.
- gcp 9y ago
  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.
  - _nalply 9y ago
    Eating a broom is a German saying: «Eher fress ich einen Besen...!».
    - WaltPurvis 9y ago
      Thank you! I was just about to ask about the origins of that phrase (which I've never heard before).
- jchw 9y ago
  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.
- deleted 9y ago
  [deleted]
avaer 9y ago
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.
- josteink 9y ago
  > 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)
  - gorhill 9y ago
    > If the browser says "You can't do that", I can't do that. Consider WebExtensions Experiments: https://webextensions-experiments.readthedocs.io/en/latest/why.html https://webextensions-experiments.readthedocs.io/en/latest/w...
- callumlocke 9y ago
  > 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.
martinsbalodis 9y ago
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.
piyush_soni 9y ago
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. [0] : https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/ https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...
- gcp 9y ago
  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.
  - piyush_soni 9y ago
    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.
    - bzbarsky 9y ago
      > 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.
ahmedfromtunis 9y ago
But will Google allow this to happen, as it would strip them a huge selling point for Chrome?
- josteink 9y ago
  Please elaborate. What selling point for Chrome are you talking about?
  - gcp 9y ago
    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)
    - josteink 9y ago
      But Firefox can already run WebExtensions (aka Chrome extensions). So how does this change anything?
      - gcp 9y ago
        It can. 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.
        josteink 9y ago
        I know all about the issues with Firefox, the new WebExtensions and how the "old" XUL extensions which let you do "anything" are being phased out. 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?
OliverJones 9y ago
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]
- OliverJones 9y ago
  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.
  - ivm 9y ago
    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.
  - Manishearth 9y ago
    > 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?)
xg15 9y ago
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.
- vec 9y ago
  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.
- nsgi 9y ago
  Unfortunately that would be practically difficult with Chrome only allowing extensions downloaded from the Chrome Web Store.
  - fny 9y ago
    The package format could apply to how extensions are deployed to the store at least. Also, I know it's possible to run third-party extensions in developer mode.
gwbas1c 9y ago
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.
- vec 9y ago
  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.
- Sylos 9y ago
  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.
erikrothoff 9y ago
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.
mekkkkkk 9y ago
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.
- JadeNB 9y ago
  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.
  - mekkkkkk 9y ago
    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.
    - JadeNB 9y ago
      > 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.
- aboodman 9y ago
  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.
- 9y ago
Osmium 9y ago
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. [1] https://news.ycombinator.com/item?id=14888010 https://news.ycombinator.com/item?id=14888010 (just 2 days ago!)

206 points by tbassetto 9y ago

Finally! WebExtensions (https://developer.mozilla.org/en-US/Add-ons/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/Chrome_incompatibilities 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?

Manishearth 9y ago
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.
- kbrosnan 9y ago
  One of the big differences is that Firefox and Edge do not support any of the deprecated APIs.
- weaksauce 9y ago
  > 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)
syshum 9y ago
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?
- pzone 9y ago
  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.
  - syshum 9y ago
    Pointing to another company and saying "Well they would be more evil" is not IMO a valid defense. Just because Microsoft is more anti-competitive than Google does not change anything I said
  - xg15 9y ago
    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.

fibo 9y ago

Looks a really good idea

Nyrox 9y ago

Cute idea, but I will eat a broom before this actually becomes reality.

gcp 9y ago
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.
- _nalply 9y ago
  Eating a broom is a German saying: «Eher fress ich einen Besen...!».
  - WaltPurvis 9y ago
    Thank you! I was just about to ask about the origins of that phrase (which I've never heard before).
jchw 9y ago
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.
deleted 9y ago
[deleted]

avaer 9y ago

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.

josteink 9y ago
> 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)
- gorhill 9y ago
  > If the browser says "You can't do that", I can't do that. Consider WebExtensions Experiments: https://webextensions-experiments.readthedocs.io/en/latest/why.html https://webextensions-experiments.readthedocs.io/en/latest/w...
callumlocke 9y ago
> 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.

martinsbalodis 9y ago

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.

piyush_soni 9y ago

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. [0] : https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/ https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...

gcp 9y ago
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.
- piyush_soni 9y ago
  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.
  - bzbarsky 9y ago
    > 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.

ahmedfromtunis 9y ago

But will Google allow this to happen, as it would strip them a huge selling point for Chrome?

josteink 9y ago
Please elaborate. What selling point for Chrome are you talking about?
- gcp 9y ago
  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)
  - josteink 9y ago
    But Firefox can already run WebExtensions (aka Chrome extensions). So how does this change anything?
    - gcp 9y ago
      It can. 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.
      - josteink 9y ago
        I know all about the issues with Firefox, the new WebExtensions and how the "old" XUL extensions which let you do "anything" are being phased out. 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?

OliverJones 9y ago

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]

OliverJones 9y ago
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.
- ivm 9y ago
  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.
- Manishearth 9y ago
  > 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?)

xg15 9y ago

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.

vec 9y ago
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.
nsgi 9y ago
Unfortunately that would be practically difficult with Chrome only allowing extensions downloaded from the Chrome Web Store.
- fny 9y ago
  The package format could apply to how extensions are deployed to the store at least. Also, I know it's possible to run third-party extensions in developer mode.

gwbas1c 9y ago

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.

vec 9y ago
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.
Sylos 9y ago
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.

erikrothoff 9y ago

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.

mekkkkkk 9y ago

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.

JadeNB 9y ago
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.
- mekkkkkk 9y ago
  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.
  - JadeNB 9y ago
    > 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.
aboodman 9y ago
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.
9y ago

Osmium 9y ago

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. [1] https://news.ycombinator.com/item?id=14888010 https://news.ycombinator.com/item?id=14888010 (just 2 days ago!)