WebExtensions/Applications

Status: draft

tl;dr

Let's enable the running of WebExtensions add-ons built for Chrome with zero modification in Firefox.

Rationale

Currently to run a Chrome WebExtension in Firefox you have to alter the manifest.json to include the applications data for example, this is the minimum you need to get an add-on working.

   "applications": {
       "gecko": {
           "id": "drumpfinator-firefox@donaldjdrumpf.com",
       }
   }

The downside here is that we are creating work for every add-on and add-on developer in supporting Firefox. Secondly, the addition of any metadata outside of the scope that Chrome shows a warning.

The use of an application id is something we could avoid because everything has to come through AMO to be signed and we could create it for the add-on developer.

Proposal

Please note: all the following only applies to WebExtension add-ons, other add-ons will be unchanged.

Because now all add-ons, be them hosted on AMO or hosted on a developers site have to go through AMO and be signed we now have the option to help developers out and do this for them. In the past this wouldn't have been possible.

Extra file

Move extra data into a file. Could be called mozilla.json, or applications.json or whatever (to make this easier I've called it mozilla.json from here on). That file is optional and should never be required. If it exists then AMO could use that file to populate data such as the add-on id.

Add-on developers could keep track of their add-on along with add-on if they so with, but it won't interfere with the basic operation of the add-on.

Signing

When signing a WebExtension we would go through something like the following:

• see if applications > id exists in the manifest.json (for legacy)
  • if an add-on id exists, use it for the add-on
  • continue
• see if applications > id exists in mozilla.json
  • if an add-on id exists, use it for the add-on
  • continue
• generate a new add-on id
  • generate a mozilla.json file in the add-on
  • ..or we might have to update a mozilla.json if one already exists
  • assign the add-on on AMO to that guid
  • continue

The add-on developer can find their add-on id a couple of ways:

• by accessing AMO and finding out
• by looking at mozilla.json in the signed add-on

Loading in Firefox

When Firefox loads an add-on we would go through something like the following:

• see if applications > id exists in the manifest.json (for legacy)
  • if an add-on id exists, use it for the add-on
  • continue
• see if applications > id exists in mozilla.json
  • if an add-on id exists, use it for the add-on
  • continue
• if the add-on id is not found and the add-on is being temporarily loaded through about:debugging
  • generate a random add-on id
  • continue
• if the add-on id is not found and the add-on is not being temporarily loaded, raise an error

This last point (raising an error) isn't great. What could we do about nightly and dev editions where developers could turn off the signing and then load an add-on? Just fail loudly?

API

The signing APIs for addons.mozilla.org are currently keyed off the add-on id. Developers using the API would need to know the add-on id, or specify it in mozilla.json.

To fix this, we also propose changing the AMO signing API from PUT /api/v3/addons/[string:addon-id]/versions/[string:version]/ to PUT /api/v3/addons/ and having the server pull the addon-id and version out of the submitted XPI (or generate them if they're missing). (We should also return that data as fields in the response, so that the calling script would know what they were going to be.)

Tools like web-ext could go through the same steps as AMO.

Validator

We'd have to alter the validator with the changes to the files and make the applications and mozilla.json optional.

Out of scope

Compatibility

Compatibility checks for Chrome Add-ons submitted to AMO and/or for signing would be required. Add-ons that use unsupported APIs should be flagged and/or rejected to avoid user confusion/consternation.

Please see bug 1337.