4 ms·

There's been a lot of misinformation about the extensions changes out there; what are you worried about? Most of the worries about the upcoming Firefox changes

There's been a lot of misinformation about the extensions changes out there; what are you worried about? Most of the worries about the upcoming Firefox changes to addons seem to come out of this misinformation :)

reitanqild 10y ago
> what are you worried about? It is said to be similar to chromes. And chrome doesn't support real extensions like tree style tabs etc. Happy if you can tell me I am misinformed.
- pauljohncleary 10y ago
  Extensions are a form of vendor lock in, Google were killing Mozilla in that space because: - network effects (chrome is more popular than ff) - chrome extensions are so much easier to write than XUL ff extensions Now webextensions are implemented in FF, it's incredibly easy to port extensions across (I ported one earlier this week, took about 20 minutes!) Tree style tabs and all that jazz aren't going away yet. It's a killer move from Mozilla and makes FF a first class citizen of the web again.
  - Sir_Cmpwn 10y ago
    The primary concerns I have, which I left Firefox over, are: - Dropping XUL breaks backwards compatability and it seems Mozilla is willing to break it before they provide adequate replacement APIs - The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that
    - paulryanrogers 10y ago
      Technically you don't have to distribute through Mozilla, just submit for signing. While it's true they remain a gatekeeper it's not as bad as the IOS app-store.
    - rhelmer 10y ago
      > Dropping XUL breaks backwards compatability and it seems Mozilla is willing to break it before they provide adequate replacement APIs The problem is not XUL. Modifying HTML or XUL DOM via JS is roughly equivalent (setting aside XUL-only features like XBL, does this matter for many extensions?) The problem is all the internal JS APIs that add-ons can call right now, there are too many to secure and ensure backwards compat. This is why extensions break between releases so much. It's also pretty hard to program against, so there are a lot of common bugs and it's very difficult to ensure any level of security, since Firefox extensions can do anything. WebExtensions are intended to be a superset of the APIs Chrome exposes, new APIs are being added all the time. It must be possible to implement them securely and maintain them over time, unlike the current situation with internal-only APIs. > The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that I disagree. Signing is required to make it more difficult for malicious extensions to persist in the wild. There's no requirement to host on AMO, just a requirement to sign if you want your extension to run in Firefox release builds. If the extension is later found to be malicious, it can be revoked without having to depend on the ID (which is set by the add-on and trivial to circumvent). > The primary concerns I have, which I left Firefox over Which browser did you switch to? There's still time to participate and influence outcomes, old-style extensions are still supported today...
  - Akkuma 10y ago
    It isn't just that chrome extensions are easier to write than XUL ff extensions. It is also that XUL ff extensions are poorly maintained in various ways with more gotchas. Additionally, FF's extension signing was largely a mess and in less than a year we're transition from JPM to another build tool. You can't even go from unlisted to listed on Firefox's addon site.
  - reitanqild 10y ago
    My question still stands though: Will the new Firefox support real extensions or just wannabe-extensions like Chrome?
    - rhelmer 10y ago
      WebExtensions are a superset of what Chrome does. Things like tree-style tabs will be possible in Firefox with the new extension system, for instance. There are already several WebExtension APIs implemented that Firefox supports that Chrome does not, the difference now is that APIs are being built specifically for extension authors to use, rather than Firefox internals being directly accessible (which certainly allows you to modify anything, but is intractable to maintain backwards compat and secure). Many authors of popular extensions are working on specifying and prototyping the APIs they need.
- Manishearth 10y ago
  Yes, that is wrong :) So what's happening is that the extension stuff is going to be standardized, and that standard will be closer to Chrome's model. However, this doesn't mean that functionality will be lost -- this is the key bit of confusion around this that's causing all the resentment. Instead, the protocol will be extended. The intention is so that almost all extensions, especially the popular ones like tree style tabs, will keep on working; however they will need to be written to work with the new APIs. Functionality from Firefox's API will only be removed when there is something on the webextensions side that gives the same abilities. The current system lets plugin developers directly hook into Firefox source, which means that theoretically any change is a breaking change. Architectural overhauls like electrolysis were impeded by this too. Instead, the desire is to switch to a proper API that is separate from the inner functionality; which is basically a core principle of API design. Chrome already does this -- the API is limited -- but the generic model is the right one. The plan is to do something similar in Firefox, with a much larger API (eventually) than what Chrome has. At first, probably just the Chrome API will be implemented, but IIRC regular firefox addon APIs will not be removed until the corresponding APIs exist in the webextensions format. This will mean that authors of old addons may need to put some work into it to make it work again (which they had to do anyway for electrolysis, really). Also, obscure addons using very random internal APIs may also break entirely. But for the most part the average addon user shouldn't notice anything.
  - reitanqild 10y ago
    > Yes, that is wrong :) Fantastic news, thanks! > The intention is so that almost all extensions, especially the popular ones like tree style tabs, will keep on working; however they will need to be written to work with the new APIs. This sounds doable. > but IIRC regular firefox addon APIs will not be removed until the corresponding APIs exist in the webextensions format. Again, this should sort it. My worry was if we would be left with only chrome-like or worse browsers - for me Firefox currently plays in different league. Edit: you possibly see why I and others were mistaken; you are the first one I know that has explained this. Feel free to tell relevant people why we misunderstood so we can clear up the FUD.
    - 10y ago
- the_duke 10y ago
  The docs @ Mozilla refer to the "WebExtensions" API, as if it was a standard. Google get's me nothing though, except the Chrome API and Operas copy thereof. So Mozilla basically just said: "Let's just copy the Chrome APIs. Done" Don't get me wrong, I've written some Chrome extensions, and I think the API is mostly pretty great. But wouldn't an actual standard be appropriate?
  - rhelmer 10y ago
    Standardization would be a useful outcome, having multiple implementations shipping is a prerequisite as I understand it - it's something Mozilla could participate in, along with other interested browser vendors. There's a community group: https://www.w3.org/community/browserext/ https://www.w3.org/community/browserext/ but no WG yet as far as I can tell.

reitanqild 10y ago

> what are you worried about? It is said to be similar to chromes. And chrome doesn't support real extensions like tree style tabs etc. Happy if you can tell me I am misinformed.

pauljohncleary 10y ago
Extensions are a form of vendor lock in, Google were killing Mozilla in that space because: - network effects (chrome is more popular than ff) - chrome extensions are so much easier to write than XUL ff extensions Now webextensions are implemented in FF, it's incredibly easy to port extensions across (I ported one earlier this week, took about 20 minutes!) Tree style tabs and all that jazz aren't going away yet. It's a killer move from Mozilla and makes FF a first class citizen of the web again.
- Sir_Cmpwn 10y ago
  The primary concerns I have, which I left Firefox over, are: - Dropping XUL breaks backwards compatability and it seems Mozilla is willing to break it before they provide adequate replacement APIs - The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that
  - paulryanrogers 10y ago
    Technically you don't have to distribute through Mozilla, just submit for signing. While it's true they remain a gatekeeper it's not as bad as the IOS app-store.
  - rhelmer 10y ago
    > Dropping XUL breaks backwards compatability and it seems Mozilla is willing to break it before they provide adequate replacement APIs The problem is not XUL. Modifying HTML or XUL DOM via JS is roughly equivalent (setting aside XUL-only features like XBL, does this matter for many extensions?) The problem is all the internal JS APIs that add-ons can call right now, there are too many to secure and ensure backwards compat. This is why extensions break between releases so much. It's also pretty hard to program against, so there are a lot of common bugs and it's very difficult to ensure any level of security, since Firefox extensions can do anything. WebExtensions are intended to be a superset of the APIs Chrome exposes, new APIs are being added all the time. It must be possible to implement them securely and maintain them over time, unlike the current situation with internal-only APIs. > The design of the new addon signature requirements turns AMO into a walled garden and I very much do not appreciate that I disagree. Signing is required to make it more difficult for malicious extensions to persist in the wild. There's no requirement to host on AMO, just a requirement to sign if you want your extension to run in Firefox release builds. If the extension is later found to be malicious, it can be revoked without having to depend on the ID (which is set by the add-on and trivial to circumvent). > The primary concerns I have, which I left Firefox over Which browser did you switch to? There's still time to participate and influence outcomes, old-style extensions are still supported today...
- Akkuma 10y ago
  It isn't just that chrome extensions are easier to write than XUL ff extensions. It is also that XUL ff extensions are poorly maintained in various ways with more gotchas. Additionally, FF's extension signing was largely a mess and in less than a year we're transition from JPM to another build tool. You can't even go from unlisted to listed on Firefox's addon site.
- reitanqild 10y ago
  My question still stands though: Will the new Firefox support real extensions or just wannabe-extensions like Chrome?
  - rhelmer 10y ago
    WebExtensions are a superset of what Chrome does. Things like tree-style tabs will be possible in Firefox with the new extension system, for instance. There are already several WebExtension APIs implemented that Firefox supports that Chrome does not, the difference now is that APIs are being built specifically for extension authors to use, rather than Firefox internals being directly accessible (which certainly allows you to modify anything, but is intractable to maintain backwards compat and secure). Many authors of popular extensions are working on specifying and prototyping the APIs they need.
Manishearth 10y ago
Yes, that is wrong :) So what's happening is that the extension stuff is going to be standardized, and that standard will be closer to Chrome's model. However, this doesn't mean that functionality will be lost -- this is the key bit of confusion around this that's causing all the resentment. Instead, the protocol will be extended. The intention is so that almost all extensions, especially the popular ones like tree style tabs, will keep on working; however they will need to be written to work with the new APIs. Functionality from Firefox's API will only be removed when there is something on the webextensions side that gives the same abilities. The current system lets plugin developers directly hook into Firefox source, which means that theoretically any change is a breaking change. Architectural overhauls like electrolysis were impeded by this too. Instead, the desire is to switch to a proper API that is separate from the inner functionality; which is basically a core principle of API design. Chrome already does this -- the API is limited -- but the generic model is the right one. The plan is to do something similar in Firefox, with a much larger API (eventually) than what Chrome has. At first, probably just the Chrome API will be implemented, but IIRC regular firefox addon APIs will not be removed until the corresponding APIs exist in the webextensions format. This will mean that authors of old addons may need to put some work into it to make it work again (which they had to do anyway for electrolysis, really). Also, obscure addons using very random internal APIs may also break entirely. But for the most part the average addon user shouldn't notice anything.
- reitanqild 10y ago
  > Yes, that is wrong :) Fantastic news, thanks! > The intention is so that almost all extensions, especially the popular ones like tree style tabs, will keep on working; however they will need to be written to work with the new APIs. This sounds doable. > but IIRC regular firefox addon APIs will not be removed until the corresponding APIs exist in the webextensions format. Again, this should sort it. My worry was if we would be left with only chrome-like or worse browsers - for me Firefox currently plays in different league. Edit: you possibly see why I and others were mistaken; you are the first one I know that has explained this. Feel free to tell relevant people why we misunderstood so we can clear up the FUD.
  - 10y ago
the_duke 10y ago
The docs @ Mozilla refer to the "WebExtensions" API, as if it was a standard. Google get's me nothing though, except the Chrome API and Operas copy thereof. So Mozilla basically just said: "Let's just copy the Chrome APIs. Done" Don't get me wrong, I've written some Chrome extensions, and I think the API is mostly pretty great. But wouldn't an actual standard be appropriate?
- rhelmer 10y ago
  Standardization would be a useful outcome, having multiple implementations shipping is a prerequisite as I understand it - it's something Mozilla could participate in, along with other interested browser vendors. There's a community group: https://www.w3.org/community/browserext/ https://www.w3.org/community/browserext/ but no WG yet as far as I can tell.