WebExtensions/FAQ: Difference between revisions
Wmccloskey (talk | contribs) (add some questions) |
|||
| Line 10: | Line 10: | ||
=== I'm writing a new extension today. What API should I use? === | === I'm writing a new extension today. What API should I use? === | ||
=== | === This WebExtension API sounds limiting === | ||
We certainly don't intend it to be. Our goal is for the WebExtension API to cover every reasonable use case that addon authors have. | |||
=== Won't this limit experimentation === | |||
As is, it will. We are trying to devise a system that will allow for extension authors to have the flexibility to implement features that the WebExtension API doesn't currently allow. We will post more information about that when there is something solid to share. The intent is for add-on authors to experiment through this mechanism with the knowledge that there are no guarantees of compatibility between Firefox releases and use that to inform future additions to the WebExtension API | |||
=== I already have a XUL extension. How is this not terrible news for me? === | === I already have a XUL extension. How is this not terrible news for me? === | ||
Revision as of 21:50, 24 August 2015
It sounds like you're copying Google....
The Chrome extension API was designed to work well with process separation and we are certainly taking inspiration from it and copying functionality where it makes sense. In other areas it doesn't. For example, we don't have much interest in providing easy access to Google's services though WebExtensions. We do however want to support certain use cases that don't seem to be a priority for Google, such as ad-blocking, tab management and time/location shifting content.
Why WebExtensions and not Jetpack?
How will WebExtensions be cross-browser if you're extending Google's API
Which add-ons will stop working after the deprecation?
I'm writing a new extension today. What API should I use?
This WebExtension API sounds limiting
We certainly don't intend it to be. Our goal is for the WebExtension API to cover every reasonable use case that addon authors have.
Won't this limit experimentation
As is, it will. We are trying to devise a system that will allow for extension authors to have the flexibility to implement features that the WebExtension API doesn't currently allow. We will post more information about that when there is something solid to share. The intent is for add-on authors to experiment through this mechanism with the knowledge that there are no guarantees of compatibility between Firefox releases and use that to inform future additions to the WebExtension API
I already have a XUL extension. How is this not terrible news for me?
Talk about how we want to break extensions less.