|
|
|
|
|
by alphapapa
3698 days ago
|
|
> To your concerns regarding stable APIs: that's exactly what WebExtensions are designed to address: decoupling add-on APIs from implementation details so that we can keep add-ons working, even as we refactor Firefox to be faster, more stable, and more efficient. Ok, that sounds nice, but is this yet another extension API that does it Chrome-style, restricting extensions to a solitary button in a solitary toolbar, rather than giving them the freedom to truly extend the browser and its UI? Because if I wanted handicapped extension APIs, I'd just use Chrome. And besides, isn't that what Jetpack was supposed to be? How long until the next extension API that will get it right This Time? One of the foundational pillars of Firefox is its powerful extension API, however messy and difficult-to-refactor it may be. Take that away, and it's just another browser, no better than Chrome. |
|
WebExtensions are likely to be The One True API. Chrome, Opera, Edge, and Firefox all support them, and we're all working on standardizing them at the W3C: https://www.w3.org/community/browserext/
> If I wanted handicapped extension APIs, I'd just use Chrome.
Though we're trying to avoid reinventing wheels, we're not limiting ourselves to Chrome's APIs. For example, https://bugzil.la/1242871 extends Chrome's webRequest API to provide additional metadata needed by the NoScript and RequestPolicy add-ons. The initial development is focused on Chrome parity, since that covers most add-ons, but once we get there you'll see more of an emphasis on landing APIs that are needed by existing, more powerful Firefox add-ons.
If you're an add-on developer yourself and are concerned about APIs you need, please fill out this survey so we have a record of it: https://docs.google.com/a/mozilla.com/forms/d/1PtRXcs9UHVMjg...