Skip to content

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

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

andrewbaxter
Copy link

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.

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.
@rebloor rebloor requested a review from willdurand March 9, 2025 22:33
@rebloor
Copy link
Collaborator

rebloor commented Mar 9, 2025

@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

@andrewbaxter
Copy link
Author

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 define isn't 100% clear - I'd read it to mean "specify the key/field" with no specific relation to the value that goes in that field. Would something like "choose" (e.g. "you must choose an ID and place it in the manifest") work?

@rebloor
Copy link
Collaborator

rebloor commented Mar 12, 2025

@andrewbaxter, thoughts now? Using "create". The problem with "choose" is that it could imply the developer picks the ID from a list.

@andrewbaxter
Copy link
Author

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).
Copy link
Member

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.

Copy link
Collaborator

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.

Copy link
Member

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood, updated.

@rebloor rebloor requested a review from wagnerand March 14, 2025 16:13

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).
Copy link
Member

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.

Copy link
Collaborator

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.

Copy link
Member

@willdurand willdurand left a 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.

@rebloor rebloor requested a review from willdurand March 20, 2025 02:34
Copy link
Member

@willdurand willdurand left a 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.
Copy link
Member

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?

Copy link
Collaborator

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants