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

**URL:** <https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882>\
**Category:** addons.mozilla.org\
**Created:** [January 5, 2024, 7:50pm UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882 "2024-01-05T19:50:25Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![muzuiget](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/muzuiget/32/64316_2.png) [@muzuiget](https://discourse.mozilla.org/u/muzuiget)\
**Post date:** [January 5, 2024, 7:50pm UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/1 "2024-01-05T19:50:26Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![dotproto](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/dotproto/32/62957_2.png) [@dotproto](https://discourse.mozilla.org/u/dotproto)\
**Post date:** [January 9, 2024, 9:46pm UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/2 "2024-01-09T21:46:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![muzuiget](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/muzuiget/32/64316_2.png) [@muzuiget](https://discourse.mozilla.org/u/muzuiget)\
**Post date:** [January 12, 2024, 2:38am UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/3 "2024-01-12T02:38:58Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dotproto](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/dotproto/32/62957_2.png) [@dotproto](https://discourse.mozilla.org/u/dotproto)\
**Post date:** [January 12, 2024, 11:58pm UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/4 "2024-01-12T23:58:19Z")

</div>

> [@muzuiget](#):
>
> 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.

Developers can also provide a static extension ID by including a “key” property in the manifest during development ([Chrome docs](https://developer.chrome.com/docs/extensions/reference/manifest/key)). 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.

---

<div class="post-metadata">

**Author:** ![muzuiget](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/muzuiget/32/64316_2.png) [@muzuiget](https://discourse.mozilla.org/u/muzuiget)\
**Post date:** [January 16, 2024, 12:09pm UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/5 "2024-01-16T12:09:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![stig](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/stig/32/24662_2.png) [@stig](https://discourse.mozilla.org/u/stig)\
**Post date:** [January 17, 2024, 9:37am UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/6 "2024-01-17T09:37:01Z")

</div>

> [@muzuiget](#):
>
> All right, now we can only create separate .zip files for Chrome and Firefox.

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:

> **[background - Mozilla | MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/background#browser_support)**
>
> Use the background key to include one or more background scripts, a background page, or a Service worker in your extension.

---

<div class="post-metadata">

**Author:** ![dotproto](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/dotproto/32/62957_2.png) [@dotproto](https://discourse.mozilla.org/u/dotproto)\
**Post date:** [February 5, 2024, 1:57pm UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/7 "2024-02-05T13:57:00Z")

</div>

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"
}
```

---

<div class="post-metadata">

**Author:** ![muzuiget](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/muzuiget/32/64316_2.png) [@muzuiget](https://discourse.mozilla.org/u/muzuiget)\
**Post date:** [February 6, 2024, 11:38pm UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/8 "2024-02-06T23:38:30Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![dotproto](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/dotproto/32/62957_2.png) [@dotproto](https://discourse.mozilla.org/u/dotproto)\
**Post date:** [February 7, 2024, 3:05am UTC](https://discourse.mozilla.org/t/allow-upload-zip-file-without-extension-id-via-amo-web-ui/125882/9 "2024-02-07T03:05:53Z")

</div>

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](https://issues.chromium.org).