-
Notifications
You must be signed in to change notification settings - Fork 136
Clarify extension ID creation #2022
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
For manifest V3, the developer must come up with an ID on their own to submit the extension. I clarified it (I think in the best location) and provided details on the requirements and how to to choose one.
@andrewbaxter I've made some suggestions which I think may simplify things i.e., recommending setting the extension ID for a manifest V3 extension from the start |
src/content/documentation/develop/extensions-and-the-add-on-id.md
Outdated
Show resolved
Hide resolved
src/content/documentation/develop/extensions-and-the-add-on-id.md
Outdated
Show resolved
Hide resolved
Oh this is great and very thorough! Thanks! It's a very small thing but (I just mentioned it in the other PR too) I think |
Co-authored-by: Andrew Baxter <[email protected]>
@andrewbaxter, thoughts now? Using "create". The problem with "choose" is that it could imply the developer picks the ID from a list. |
Yeah, sorry, I think that's probably okay. IMO choose is appropriate here - you're choosing from the set of potential ids, and such wording is widely used elsewhere (i.e. choose a name, choose a location, choose a color, etc). Create is still ambiguous as to the true agent, as in "create an ID by registering it in AMO" is natural and common, whereas you'd never see "choose an ID by registering it in AMO" (and meaning-wise it's nonsensical). There's no potential for confusion about choosing from a list; none of the documentation suggests the existence of a list, unlike the ambiguity regarding an agent since an agent (AMO) does exist and provides you with an ID in certain documented circumstances, but I don't want to force this point. |
|
||
For [Manifest V3 extensions](/documentation/develop/manifest-v3-migration-guide/) you must create the add-on ID and add it to your extension's manifest.json file before it's submitted to AMO (online, using [webext](/documentation/develop/web-ext-command-reference/), or the [AMO API]((https://addons-server.readthedocs.io/en/latest/topics/api/v4_frozen)). It's recommended that you set your extension ID when you begin development. | ||
|
||
You can define an ID for a Manifest V2 extension in its manifest.json file before submission, but if you don't, AMO assigns your extension an ID when [your extension is first signed](/documentation/publish/#get-your-extension-signed). See [Working without an ID in Manifiest V2](#working-without-an-id-in-manifiest-v2). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think AMO will actually create the ID when the add-on instance is created on AMO, which is before the add-on is signed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this is undoubtedly technically correct, I've followed the AMO processes through for on-site publication and self-distribution, and effectively, you can't distinguish between ID assignment and signing as two separate events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are several scenarios where you can and when this becomes relevant. For example when a developer pauses or aborts the submission process or when an add-on (for whatever reason) is not auto-approved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, updated.
src/content/documentation/develop/extensions-and-the-add-on-id.md
Outdated
Show resolved
Hide resolved
|
||
For [Manifest V3 extensions](/documentation/develop/manifest-v3-migration-guide/) you must create the add-on ID and add it to your extension's manifest.json file before it's submitted to AMO ([online](/documentation/publish/submitting-an-add-on/) or using [`web-ext sign`](/documentation/develop/web-ext-command-reference/#web-ext-sign) or the [AMO API create endpoint](https://mozilla.github.io/addons-server/topics/api/addons.html#create)). It's recommended that you set your extension ID when you begin development. | ||
|
||
You can define an ID for a Manifest V2 extension in its manifest.json file before submission. If you don't, AMO assigns your extension an ID when you submit it to AMO (online or using `web-ext sign` or the AMO API create endpoint). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's recommend developers to always add their own ID explicitly in the manifest instead of making it a MV2 vs. MV3 thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@willdurand let me know what you think of the revision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting changes to discuss about my comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r+wc, thanks
## Basic workflow with no add-on ID (Manifest V2) | ||
|
||
An add-on ID is usually optional for Manifest V2 extensions. If you don't set it, you can generally develop, debug, publish, and update your extension without ever having to deal with an ID. One advantage of this is that Google Chrome does not recognize the `browser_specific_settings` key and shows a warning if you include it. | ||
An add-on ID is optional for Manifest V2 extensions. If you don't set it, you can generally develop, debug, publish, and update your extension without ever having to deal with an ID. One advantage of this is that Google Chrome does not recognize the `browser_specific_settings` key and shows a warning if you include it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One advantage of this is that Google Chrome does not recognize the
browser_specific_settings
key and shows a warning if you include it.
That doesn't sound right or great if true. Isn't bss
supposed to be designed exactly for this purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dotproto I've taken one of the Chrome extension examples and added browser_specific_settings
to it, then loaded it as an unpacked file. Chrome reported no errors or warnings. Can you confirm the statement about a warning in Chrome for browser_specific_settings
is incorrect/updated?
AFAICT nowhere in the docs did it say that the developer can come up with the extension ID on their own, and in several places it's suggested that they don't come up with it on their own (ex: testing locally, uploading manifest V2 extensions with no ID).
For manifest V3, the developer must come up with an ID on their own to submit the extension. This confused me for several hours until I joined the addons web chat and got an answer from someone official.
In this MR I clarified it (I think in the best location) and provided details on the requirements and how to to choose one.
Related: mdn/content#38444 - I also made changes here because this information is spread in multiple places so people might not find one or the other, and without this clarification reading the wrong document could lead someone to think they have the (wrong) answer and stop searching at that point.