Confirm
1,158
edits
Changes
Created page with "Status: '''draft''' WebExtensions is an implementation of Chromes Extension API, as such the initial implementation is limited to the choices made by Chrome. At Firefox, we w..."
Status: '''draft'''
WebExtensions is an implementation of Chromes Extension API, as such the initial implementation is limited to the choices made by Chrome. At Firefox, we would like to go beyond that implementation and give developers the ability to create add-ons that change many more aspects of Firefox whilst keeping in with the themes of API stability and user security.
We want to allow new API's, but we can't just allow everything. Here's a criteria for how we could look at new API's.
This document is currently a draft, feedback is wanted. This is based on a conversation at the WebExtensions work week in Berlin in March 2016. There will probably be some updates after that.3
= Rationale =
New APIs will need to be built and people will request them. Sadly not all of them should be added, we need a criteria for deciding what should and shouldn't be added so we can be '''consistent and transparent''' with our choices.
= Criteria =
When we evaluate a new API we should look at, in no particular order:
* Alternative: are there alternatives for doing this, so we don't have to write an API?
** everything that we write is something we have to maintain
** concerned APIs that are locked away in WebExtensions and not available to the web
* Usage: is there any evidence that this API is used in current add-ons?
** this may, or may not, be a good indicator of the potential usage of the add-on
* Maintenance: is this going to be a particular burden to maintain?
** we've seen examples of this kind of API in the past, specifically around XUL and APIs that interact with the UI
** we should be considering not just support for us, but also the whole Firefox and Mozilla code base as a whole
* Security: does the API expose unacceptable risk for the end user?
* Performance: does the API create an unacceptable performance penalty for the add-on user?
== Examples ==
At the Berlin work week, we ran through a few scenarios and talked about them to see how this process would work. These are just examples as we learnt the process.
=== Enable "TCP and UDP Socket API" ===
{{ Bugzilla|1247628}}
* Was suggested that TCP and UDP should be seperated out and made seperate from the each other. Focusing on TCP should be the first goal.
* TCP support is useful for many add-ons and there should be many examples we could find.
* Code already exists for this in Firefox, this will be just a wrapper around the APIs.
* There were security concerns about these API and would have to be a special permission the user would have to enable (at the very least).
Verdict? Yes, but questions about the security concerns.
=== Implement WebSQL ===
{{ Bugzilla|1247329}}
* Concerns about WebSQL as not a successful standard.
* No overwhelming reason to support this.
* There are already many libraries that exist outside of WebExtensions wrap around IndexedDB and give developers access to sane APIs. Local forage is one example.
* Concerns about maintenance of such an API.
Verdict? No.
=== Implement an API for location bar ===
{{ Bugzilla|1215060}}
* Maybe we could make it an iframe they could inject.
* Should be simple to maintain.
* No real security or performance problems.
Verdict? Yes
= Submitting an API? =
If you have an API you'd like to see implemented, then:
Currently:
* file a new bug in Toolkit > Web Extensions
Future:
* we are looking at landing something like WebExtensions/Experiments
* when that happens, we'd get a process of suggesting and submitting an API through that
WebExtensions is an implementation of Chromes Extension API, as such the initial implementation is limited to the choices made by Chrome. At Firefox, we would like to go beyond that implementation and give developers the ability to create add-ons that change many more aspects of Firefox whilst keeping in with the themes of API stability and user security.
We want to allow new API's, but we can't just allow everything. Here's a criteria for how we could look at new API's.
This document is currently a draft, feedback is wanted. This is based on a conversation at the WebExtensions work week in Berlin in March 2016. There will probably be some updates after that.3
= Rationale =
New APIs will need to be built and people will request them. Sadly not all of them should be added, we need a criteria for deciding what should and shouldn't be added so we can be '''consistent and transparent''' with our choices.
= Criteria =
When we evaluate a new API we should look at, in no particular order:
* Alternative: are there alternatives for doing this, so we don't have to write an API?
** everything that we write is something we have to maintain
** concerned APIs that are locked away in WebExtensions and not available to the web
* Usage: is there any evidence that this API is used in current add-ons?
** this may, or may not, be a good indicator of the potential usage of the add-on
* Maintenance: is this going to be a particular burden to maintain?
** we've seen examples of this kind of API in the past, specifically around XUL and APIs that interact with the UI
** we should be considering not just support for us, but also the whole Firefox and Mozilla code base as a whole
* Security: does the API expose unacceptable risk for the end user?
* Performance: does the API create an unacceptable performance penalty for the add-on user?
== Examples ==
At the Berlin work week, we ran through a few scenarios and talked about them to see how this process would work. These are just examples as we learnt the process.
=== Enable "TCP and UDP Socket API" ===
{{ Bugzilla|1247628}}
* Was suggested that TCP and UDP should be seperated out and made seperate from the each other. Focusing on TCP should be the first goal.
* TCP support is useful for many add-ons and there should be many examples we could find.
* Code already exists for this in Firefox, this will be just a wrapper around the APIs.
* There were security concerns about these API and would have to be a special permission the user would have to enable (at the very least).
Verdict? Yes, but questions about the security concerns.
=== Implement WebSQL ===
{{ Bugzilla|1247329}}
* Concerns about WebSQL as not a successful standard.
* No overwhelming reason to support this.
* There are already many libraries that exist outside of WebExtensions wrap around IndexedDB and give developers access to sane APIs. Local forage is one example.
* Concerns about maintenance of such an API.
Verdict? No.
=== Implement an API for location bar ===
{{ Bugzilla|1215060}}
* Maybe we could make it an iframe they could inject.
* Should be simple to maintain.
* No real security or performance problems.
Verdict? Yes
= Submitting an API? =
If you have an API you'd like to see implemented, then:
Currently:
* file a new bug in Toolkit > Web Extensions
Future:
* we are looking at landing something like WebExtensions/Experiments
* when that happens, we'd get a process of suggesting and submitting an API through that
