I made a similar change for documents in extension workshop since there are different routes in the documentation: mozilla/extension-workshop#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

• /en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_specific_settings

(comment last updated: 2025-04-30 03:01:02)

@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.

@andrewbaxter better?

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

@andrewbaxter any objections to merging?

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.

Thanks @andrewbaxter
Any further comment @willdurand

@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