Allow upload .zip file without extension ID via AMO web UI

Add-ons addons.mozilla.org
#1

I updated an extension to Manifest V3 on Chrome a year ago, but because Firefox lacked support for the Manifest V3 API, I kept it in Manifest V2 on Firefox.

Now, I have ported the extension for Firefox to Manifest V3.

When I uploaded the Manifest V3 .zip file via the AMO web UI, the validation indicated that it should have an extension ID.

Then, I created a random GUID as the extension ID, but the validation stated that the ID did not match the existing ID from an earlier version.

So, I changed the extension ID to the existing one, and this time it passed the validation.

Therefore, I have to create two .zip files for Chrome and Firefox; the only difference is the manifest.json file, which either has the browser_specific_settings property or not.

If AMO already knows the extension ID, why not allow the upload of a .zip file without an extension ID, so we can upload the same .zip for all browsers?

2 Likes
#2

AMO requires that extension developers provide the ID because this value is pulled out of the zip file at a couple different during the submission flow. Without the extension ID, the binary asset that developers submit would not have all the information necessary to uniquely identify the submission after upload.

What happens if you try to upload the Firefox version of the zip to CWS? If CWS rejects it or Chrome refuses to load it, that feels me to like the Chrome team should relax these restrictions.

#3

What happens if you try to upload the Firefox version of the zip to CWS?

I haven’t tried that yet.

However, in Chrome, after loading it will display an error: Unrecognized manifest key 'browser_specific_settings', but the extension can still run normally.

Chrome does not need an extension ID, it automatically creates one for each extension:

  • When installed via developer mode, it’s the hash value of the file system path.
  • When installed via Chrome Web Store, it’s a fixed ID created by the Chrome Web Store.

Therefore, the same extension code can be installed in multiple instances, which are independent of each other and do not conflict. This is especially useful in development and debugging, for example, to identify which version introduced a bug.

Firefox enforces setting a fixed extension ID in manifest.json. When installing multiple instances, it’s not very clear if there will be a conflict with the extension ID.

#4

Developers can also provide a static extension ID by including a “key” property in the manifest during development (Chrome docs). Extensions downloaded from CWS and unpacked locally will also contain a “key.”

Firefox enforces setting a fixed extension ID in manifest.json . When installing multiple instances, it’s not very clear if there will be a conflict with the extension ID.

Firefox does not require extensions to specify browser_specific_settings.gecko.id, but AMO does. If you’d like to load multiple versions of the same extension simultaneously for development purposes, make sure that this property is not set in the copies. This same guidance applies to Chrome and the key manifest key.

#5

All right, now we can only create separate .zip files for Chrome and Firefox.

#6

Have you tried Chrome 121 (stable release expected 23rd January)?

I haven’t got any Chrome 121 installed, but I have an MS Edge Dev-edition based on Chromium 122, and that allows me to install an extension of mine with browser_specific_settings.gecko.id defined in the manifest file.

Recently Apple, Mozilla and Microsoft agreed to do some initiatives to reduce the needs of creating individual versions for every browser. Among the changes are that google will allow you to define both background.service_worker and background.script in same manifest but only use service_worker. This change should be effective from Chrome 121+. But I got the impression that they would try to fix other compatibility issues too, probably also from Chrome/Chromium 121+.

I cannot remember where I originally read about the meeting and plans, but when it comes to browsers compatibility (and tolerance) regarding background.service_worker vs background.scripts, it is documented here:

#7

Yep, I can confirm that the ability to use both background.scripts and background.service_worker entries in a single manifest was a recent topic of discussion in the WebExtensions Community Group and that Firefox and Chrome have been updated to support this pattern. In order to prevent older browser versions from trying to install or update to a new extension version that uses this feature, I’d strongly recommend declaring minimum browser version support in your manifest.json.

{
  "name": "Combined manifest demo",
  "version": "1.0",
  "manifest_version": 3,
  "background": {
    "scripts": ["background.js"],
    "service_worker": "background.js"
  },
   "browser_specific_settings": {
    "gecko": {
      "id": "combined_demo@example.com",
      "strict_min_version": "121.0a1"
    },
    "gecko_android": {
      "strict_min_version": "121.0a1"
    }
  },
  "minimum_chrome_version": "121"
}
#8

I tried it on the latest Chrome 121, it still has the browser_specific_settings error.

#9

While the link from the chrome://extensions page is labeled “Errors”, the browser_specific_settings message is actually a warning.

Chrome does not provide a way to silence warnings for specific unknown keys. If you’d like to a feature like that, I’d suggest opening a feature request on the Chromium issue tracker: https://issues.chromium.org.