To allow Chrome add-ons to be run without a developer having to do anything, we'd like to be assign an add-on id temporarily if one does not exist. For WebExtensions only. This could apply to add-ons loaded temporarily and unsigned, but if we could do it for an add-on loaded anyway that would be cool When an add-on is signed by AMO it would be given an add-on id in mozilla.json, so it might make sense to check that this should only apply to unsigned add-ons.

My first naive stab at this was just to add code to ExtensionData.readManifest() to insert an id if one doesn't exist, right before validating the manifest. But we end up calling readManifest() twice, once from AddonInstall.loadManifest() (or XPIProvider.installTemporaryAddon -> loadManifestFromFile() ), then again from Extension.startup(). There are lots of potential ways to skin this cat but I'd like to have the install/xpi code just stash the manifest in the addonData that is passed into the extension so the extension doesn't need to re-parse and validate the manifest. Before I dive in, any objections or does this plan have a flaw I am overlooking?

In general, the add-on manager only reads the manifest at install time, not during normal startups, so handling the manifest that way adds a lot of complications. I think the better solution is probably to change the ExtensionData class so that it doesn't overwrite the `id` when we already have one from `addonData`.

Yup, good points, thanks!

One problem here is that we're going to allocate new machine-local UUIDs (https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/Extension.jsm#496) that get stored in prefs and the value of extensions.webextesnsions.uuids is just going to grow and grow over time when people use this feature. Actually it already appears to be the case that extensions are never removed from that list, so this isn't a new problem, I just worry that it will be exacerbated by this change.

rolling this into 1262005