> 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.
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.
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.
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.
Right. There's been a lot of FUD on this and not enough has been explicitly said. I'm pretty sure this was clearly stated in some places, but FUD spreads easily :)
Maybe I can convince someone to write something about it.
You should come chat in #webextensions, if we can identify where messaging is falling down and fix it this would be great!
I think one thing missing right now is having good "release criteria" for WebExtensions (like we did for e10s) - I don't think implementing every single API that's available to old-style extensions right now is a tractable problem (since it's "every internal API", all the way up to executing arbitrary commands).
yes, of course, its not every internal API but the bottom line is that most extensions should still work, right? :)
Or are you guys going to implement every single incompatible addon yourself?
- 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.
- 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
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...
You can't even go from unlisted to listed on Firefox's addon site.
Will the new Firefox support real extensions or just wannabe-extensions like Chrome?
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.
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?
There's a community group: https://www.w3.org/community/browserext/ but no WG yet as far as I can tell.