mdn
Clarify extension ID creation
Description
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.
Motivation
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).
This confused me for several hours until I joined the addons web chat and got an answer from someone official.
Additional details
Related issues and pull requests
I made a similar change for documents in extension workshop since there are different routes in the documentation: https://github.com/mozilla/extension-workshop/pull/2022
A lot of documents are still heavily V2-oriented... I have no strong preference for V3 but I didn't want to have to make large changes to distribute an extension on multiple extension marketplaces, in case this is because V3 extensions aren't officially recommended.
Preview URLs
External URLs (2)
URL: /en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_specific_settings
Title: browser_specific_settings
- https://en.wikipedia.org/wiki/Universally_unique_identifier (1 time) (Note! This may be a new URL 👀)
- https://extensionworkshop.com/documentation/develop/extensions-and-the-add-on-id/ (1 time) (Note! This may be a new URL 👀)
(comment last updated: 2025-06-03 03:11:32)
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@andrewbaxter thanks for spotting this. I've made some additional changes as I'm not sure, for example, that the original statement that the key was usually not required was neither accurate or helpful.
Thanks! I agree, and your changes seem great - I was afraid to make sweeping changes but I think this is much better.
Would it be possible to clarify that the id is something the developer chooses, and not something assigned by ADO? That was the other thing that confused me, and since there are situations where the developer doesn't choose the id (local testing, manifest v2) it wasn't obvious to me in v3 that the roles had switched.
Oh thanks! And sorry for my insistance here!
I think the new wording doesn't explicitly say that the developer chooses the ID. It makes it clear that AMO does not, but leaves a gap in identifying who does.
If you don't have any objection, I think it would be good to say something like, "In manifest V3, the developer chooses the ID." or something similarly direct.
Edit: Rereading it I think what you wrote works, I think my only hesitation is that provide can and often means "via some external system". Like if a bank says "provide your social security number", they don't mean "make up a number". I have a similar reservation about the word "define" and was why I went with "decide" originally which I think is unambiguous (same with "choose"), but I think if someone reads this carefully they'll get the intended meaning.
This pull request has merge conflicts that must be resolved before it can be merged.
I made a similar change for documents in extension workshop since there are different routes in the documentation: mozilla/extension-workshop#2022
let's align on this first
Oh hey, sorry - I think the current state of this MR is fairly far from what I started with and I'm not on top of all of the discussions, so it might be better if you reach a conclusion with @willdurand
I think it'd be fine to merge whatever you two agree on.
@rebloor it's kind of OK. I guess I'll insist on recommending to always set an ID in the manifest no matter the manifest version, and also indicate that the important part in "email-like form" is "like", which means the developer doesn't necessarily have to own the email address because it is actually not necessarily an email address. The rest looks very reasonable. Since I am guessing I'll make the same comments in the EW PR, I'm wondering if this page should point to EW for the specifics, and do not try to explain what values are accepted, etc. idk
@willdurand I've made some updates along the lines of your feedback. Regarding. "I'm wondering if this page should point to EW for the specifics, and do not try to explain what values are accepted, etc. idk" as the information is relatively simple and unlikely to change, I'm disinclined to make the reader follow a link to get this information.
This pull request has merge conflicts that must be resolved before it can be merged.
This pull request has merge conflicts that must be resolved before it can be merged.