WebExtensions/NewAPIs: Difference between revisions

Latest revision as of 17:14, 1 August 2018

You want to request a new API for WebExtensions?

Great. But please read through the following before filing a bug:

If you are migrating your add-on to WebExtensions, please check this page to see if all the APIs you need are already available.
If you don't find what you need, please check the list of approved APIs and add yourself to the bug that applies to you to track its progress.
Join the dev-addons mailing list to find out when the next API triage is scheduled and which APIs are on the agenda so you can follow along or provide input.

If none of these options address your situation, consider filing an API request. Before you do, please keep in mind:

New API must meet the guidelines outlined the WebExtensions API Policy. Please review it.
We do try to review all incoming API requests, but it takes time, so please be patient.
Do a search to see if the bug exists already.
Still want to file a new API? You can do so here.

Goals are set out in the vision document.

@@ Line 1: / Line 1: @@
-Status: '''draft'''
+You want to request a new API for WebExtensions?
-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.
+Great. But please read through the following before filing a bug:
-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.
+* If you are migrating your add-on to WebExtensions, please check [https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API this page] to see if all the APIs you need are already available.
+* If you don't find what you need, please check [https://mzl.la/2OyUD9u the list of approved APIs] and add yourself to the bug that applies to you to track its progress.
+* Join the [https://mail.mozilla.org/listinfo/dev-addons dev-addons mailing list] to find out when the next API triage is scheduled and  which APIs are on the agenda so you can follow along or provide input.
-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
+If none of these options address your situation, consider filing an API request. Before you do, please keep in mind:
-= Rationale =
+* New API must meet the guidelines outlined the [[WebExtensions/policy|WebExtensions API Policy]].  Please review it.
+* We do try to review all incoming API requests, but it takes time, so please be patient.
+* Do a [https://mzl.la/2snQxWS search] to see if the bug exists already.
+* Still want to file a new API? You can do so [https://bugzilla.mozilla.org/enter_bug.cgi?product=WebExtensions&component=Untriaged here].
-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.
+Goals are set out in the [[WebExtensions/Vision|vision document]].
-= 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/NewAPIs: Difference between revisions

Latest revision as of 17:14, 1 August 2018

Navigation menu

Search