WebExtensions/Applications

Status: draft

tl;dr

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

Update: a few things have changed and some people came up with a much better plan that does not involve using mozilla.json, this was updated to reflect this.

Bugs, bugs

Bugzilla: 1255562 nope, this was replaced with 1262005, 1255564 Github: https://github.com/mozilla/addons/issues/61

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.

Rename field

Rename the field to browser_specific_settings. If other browsers support this key, then we can hope Chrome will start to ignore this key and not raise a warning in Chrome.

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.

The field is optional, developers can use it if they want to specify their add-on id in advance (for example if they are upgrading an old add-on to WebExtensions). Otherwise they can ignore it.

Submitting an add-on

When submitting 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
• generate a new add-on id, add it to the appropriate AMO table for that add-on

The add-on developer can find their add-on id by:

• by accessing AMO and finding out
• using the API?
• ... should we do more here?

Signing an add-on

Each time the add-on is signed (for each version), it will pull the add-on id out of the appropriate AMO table and sign it with that add-on id. The add-on id will be in the signature and be consistent for each version of that 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 on to the usual signing checks
• if the add-on is signed
  • the add-on is contained in the signing in the CN field? (should check that) of the signature
  • use that add-on id
  • continue on to the usual signing checks
• 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 to make applications and browser_specific_settings 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.