Most of our types are strictly validated; all object properties need to be accounted for, for example. This makes sense for extension APIs where this strictness allows extensions to perform feature-detection.

For static extension files, this strictness is undesirable, and bug 1253565 introduced the UnrecognizedProperty type to allow an object to accept any other object, with a warning. There are two problems with this (elaborated below), and to fix this, I propose that we should update our schema logic to:

• default to accepting unrecognized properties when validating JSON.
• drop the unrecognized properties (instead of accepting any value).

There are two problems with the current strict validation for JSON files:

• If we forget to add "additionalProperties": { "$ref": "UnrecognizedProperty" }, then extension developers are forced to either not use a manifest key, drop support for "older" Firefox versions, or to distribute different extension versions targeting different Firefox versions. Examples:
  • bug 1757293
  • bug 1775618
  • bug 1491782
  • comment 1 in bug 1828128
  • there are many more
  • In the WECG, there is broad agreement to not error unless needed: https://github.com/w3c/webextensions/issues/14
• Unrecognized properties still appear on the "validated" object. A consumer of the object cannot know whether the property was validated or whether it is a raw unvalidated value. Consequently, if a (top-level) manifest key is conditional, that exact condition needs to be repeated by its consumers, or else the consumer could potentially encounter an unvalidated value. Examples:
  • comment 1 in bug 1775618 shows a test case where ambiguity in the schema resulted in the use of unvalidated properties.
  • The sidebar_action is conditionally available (only to MOZ_BUILD_APP == "browser". In bug 1827910, toolkit code was added to check various keys including sidebar_action, under the assumption that the read manifest keys have been validated according to the schema. A test failure on Android (i.e. non-browser) shows that an "UnrecognizedProperty" value was still exposed in its raw form (see comment 9 on bug 1827910).

Notable remark:

• Firefox's implementation of the runtime.getManifest() API returns the parsed manifest (including normalization of values in some cases), which is already different from manifest.json. The proposed change here will cause unrecognized values to disappear, which can be observed by extensions and break them if they rely on the inclusion of unrecognized properties. A work-around for them is to use await (await fetch(chrome.runtime.getURL("manifest.json")).json().
  • For comparison, Chrome (and Firefox) currently includes unrecognized (top-level) keys in the manifest, and returns it as is. IIRC, Safari returns the manifest as is.

This affects all consumers of Schemas.normalize:

• manifest.json
• "native manifests": nativeMessaging, pkcs11 , managed storage (not to be confused with bug 1771731)
• declarativeNetRequest's static rule resources