WebExtensions/Applications: Difference between revisions

 
(11 intermediate revisions by 2 users not shown)
Line 9: Line 9:
== Bugs, bugs ==
== Bugs, bugs ==


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


Line 19: Line 19:
     "applications": {
     "applications": {
         "gecko": {
         "gecko": {
             "id": "drumpfinator-firefox@donaldjdrumpf.com",
             "id": "drumpfinator-firefox@donaldjdrumpf.com"
         }
         }
     }
     }
Line 35: Line 35:
== Rename field ==
== Rename field ==


Rename the field to '''browser_specific_settings''', this is part of the first proposal for a standard for WebExtensions that will be discussed by the W3C group. If other browser support this key, then we can hope Chrome will start to ignore this key and not raise a warning in Chrome.
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.
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.
Line 41: Line 41:
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.
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.


== Signing ==
== Submitting an add-on ==


When signing a WebExtension we would go through something like the following:
When submitting a WebExtension we would go through something like the following:
* see if applications > id exists in the manifest.json (for legacy)
* see if applications > id exists in the manifest.json (for legacy)
** if an add-on id exists, use it for the add-on
** if an add-on id exists, use it for the add-on
** continue
** continue
* see if browser_specific_settings > id exists in manifest.json
* generate a new add-on id, add it to the appropriate AMO table for that add-on
** if an add-on id exists, use it for the add-on
** continue
* generate a new add-on id, add it to the AMO table for that add-on


The add-on developer can find their add-on id by:
The add-on developer can find their add-on id by:
Line 56: Line 53:
* using the API?
* using the API?
* ... should we do more here?
* ... 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 ==
== Loading in Firefox ==
Line 62: Line 63:
* see if applications > id exists in the manifest.json (for legacy)
* see if applications > id exists in the manifest.json (for legacy)
** if an add-on id exists, use it for the add-on
** if an add-on id exists, use it for the add-on
** continue  
** continue on to the usual signing checks
* see if browser_specific_settings > id exists in manifest.json
** if an add-on id exists, use it for the add-on
** continue
* if the add-on is signed
* if the add-on is signed
** the add-on is contained in the signing in the CN field? (should check that) of the signature
** the add-on is contained in the signing in the CN field? (should check that) of the signature
** user that and continue
** 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
* 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
** generate a random add-on id
Line 81: Line 80:


To fix this, we also propose changing the AMO signing API from
To fix this, we also propose changing the AMO signing API from
'''PUT /api/v3/addons/[string:addon-id]/versions/[string:version]/'''
'''PUT /api/v3/addons/[string:addon-id]/versions/[string:version]/'''
to
to
'''PUT /api/v3/addons/'''
'''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).
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.)
(We should also return that data as fields in the response, so that the calling script would know what they were going to be.)
Line 92: Line 95:
== Validator ==
== Validator ==


We'd have to alter the validator make applications and '''browser_specific_settings'''.
We'd have to alter the validator to make '''applications''' and '''browser_specific_settings''' optional.


= Out of scope =
= Out of scope =
Confirmed users
1,158

edits