WebExtensions/Experiments: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Update replacement doc link)
(Per discussion with the webextensions folks, removing the other content of this page entirely.)
 
Line 1: Line 1:
= Retired =
= Retired =


'''''Most of this documentation is now out of date. Please go see https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/basics.html#adding-experimental-apis-in-privileged-extensions instead.'''''
'''''This documentation became out of date. Please go see https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/basics.html#adding-experimental-apis-in-privileged-extensions instead.'''''
 
= Overview =
 
As we move to a world of WebExtensions for add-ons we need to be able to provide more APIs than ever before to our users. We need to be able to go beyond what chrome provides to allow more flexibility and customisation than other browsers.
 
At the same time, we need to be able to move faster than the Firefox train and allow developers to be able to quickly develop and experiment with APIs. Those APIs would land in an add-on and as APIs become stable and supported they could be moved down into mozilla-central and move from "experimental" to "stable".
 
To repeat, this is the overall goal: '''be an area to allow developers to develop and experiment with APIs'''.
 
Key points:
 
* We would land experimental APIs in an add-on outside of Firefox.
 
* There would be only one WebExtensions Experiments add-on.
 
* All add-ons using WebExtensions Experiments would be dependent upon the WebExtensions Experiment.
 
* The use of WebExtensions Experiments would be declared in the manifest through a permission.
 
* Documentation would be on MDN but marked as experimental.
 
* APIs would be available in the ''browser'' namespace, and not in ''chrome''.
 
* APIs exposed by native.js extensions would be as high-level as possible. We would look for things like "open a sidebar containing HTML content", or "enter fullscreen mode". APIs exposing concepts from the internals of Firefox (e.g., channels, load groups, or particular XUL element names from browser.xul) would be forbidden.
 
* Breaking changes could occur to the WebExtensions Experiment. But would be discouraged.
 
== Policy ==
 
It's expected that when developers add in an API we are applying a rigor that is similar to what we would apply to mozilla-central - but hopefully easier to use. For example:
* code will be under MPL
* code will live on github (or similar)
* APIs should aim for the high level approach
* APIs should come with documentation and tests
* each release of WebExtensions Experiments will be tested on every version of Firefox and will be expected to pass
* releases can be frequent (eg: weekly)
 
For any API, developers submitting an API should be understanding that one of a few things can happen:
* it will be accepted and move down into mozilla-central
* it will change and be altered with the aim of improving it so it can land into mozilla-central
* it will be rejected and removed because it will not be accepted into mozilla-central
 
== Implementation ==
 
With the addition of mozilla.json, we have a bit more free reign about what is available here
 
=== Extension Type ===
 
A new extension type of 256 was added to differentiate experiments.
 
=== Example ===
 
* Implementing a simple hello world as an experiment [https://github.com/aswan/webext-experiment-hello/tree/master/extension WebExtensions Experiments Hello]
 
== Infrastructure ==
 
There is another project at Mozilla that is focused on opt-in tools to allow developers to turn on certain add-ons and provide feedback. That's [https://testpilot.mozilla.com Test Pilot] and it might make sense for us to integrate with that infrastructure instead of build our own. [https://wiki.mozilla.org/Test_Pilot Test Pilot] could potentially provide:
* a website for developers to access to get the WebExtensions Experiments add-on
* to find add-ons using WebExtensions Experiments
* to provide metrics back through the Test Pilot metrics pipeline about what add-ons are in use and the metrics within that add-on
* to collect feedback about the add-on tested when its uninstalled
 
I also like the synergy. Want to add a new feature to Firefox? You do it using Test Pilot. Adding a new feature, well you might want some APIs for that...
 
This would also require the SDK - WebExtensions transition flow to be completed to allow a WebExtensions and SDK add-on to communicate with each other.
 
== Specific limitations ==
 
This proposal is suggesting some specific limitations for the '''first release''' namely that:
* it is explicitly opt-in
* no multiple dependencies, everything in one bundle
 
The main reasons for doing this are the following:
* we need to build the infrastructure for having an add-on that does this
* dependency management is hard and I haven't seen proof of its need yet
 
If the first stage is successful, then we'll move onto the future steps (see below) that remove these limitations.
 
== Other proposals ==
 
This is based on the original proposal by [https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457 Giorgio here]. All the errors and watering down of said proposal is done by Andy. In many ways this proposal is significantly and deliberately '''scoped down''' version of that proposal. To recognise that we need to move in steps to achieve the bigger goal.
 
Chrome has an [https://developer.chrome.com/extensions/experimental experimental API].
 
= Workflow for a new API =
 
Please see docs on https://webextensions-experiments.readthedocs.io/en/latest/new.html
 
== Uplift ==
 
If the experiment results in an API that is going to land into Firefox, then we'll uplift that to mozilla-central. Any code must meet basic criteria.
 
TODO: complete this flow
 
An email to dev-addons@mozilla.com would be useful with the subject: "Intent to implement [name]" detailing the experiment that is moving up into Firefox.
 
= Milestones =
 
== Milestone 1 ==
 
* Create a prototype
* Prove that this can work
 
Status: '''complete''' [https://bugzilla.mozilla.org/show_bug.cgi?id=1263011 bug 1263011]
 
== Milestone 2 ==
 
* Automated testing of the experiment code across multiple channels
* Two APIs that work with experiment
* A first experiment add-on loaded onto AMO
** Needs [https://github.com/mozilla/addons-server/issues/3315 issue 3315] to land on github first.
 
== Milestone 3 ==
 
* [proposal] Go Faster, maybe
* [proposal] Experiment homepage, something to list the experiments, explain what to do
* [proposal] Would an uplift policy make sense
 
= Next phases =
 
== More people ==
 
Currently this proposal differs from some of the proposals in a key way, its is explicitly trying to limit the population of users to an opt-in audience. If the first phase is successful, we'd want to look at moving to more users.
 
This is similar to the differentiation between [https://wiki.mozilla.org/Test_Pilot Test Pilot] (opt-in only), Shield (a % of the audience) and [https://wiki.mozilla.org/Firefox/Go_Faster Go Faster] (all the users).
 
== More libraries ==
 
Currently this proposal limits us to one and only one Web-Extensions Experiment. In the future we might want to allow a multitude of libraries.

Latest revision as of 10:37, 9 July 2024

Retired

This documentation became out of date. Please go see https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/basics.html#adding-experimental-apis-in-privileged-extensions instead.

Retrieved from "https://wiki.mozilla.org/index.php?title=WebExtensions/Experiments&oldid=1251253"