1868153 - Inconsistency: storage.managed.get() rejects with an error when the enterprise policy is not found

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[erosman]

As posted in Inconsistency: storage.managed, please note some inconsistencies regarding the storage.managed API.
Other browsers not checked.

(async () => {

  // no catch
  console.log(await chrome.storage.managed.get());
  console.log(await browser.storage.managed.get());

  // with catch
  console.log(await chrome.storage.managed.get().catch(() => {}));
  console.log(await browser.storage.managed.get().catch(() => {}));

})();

Not found Result

Chrome

• no-catch: { }
• with-catch: { }

Firefox

• no-catch: Uncaught (in promise) Error: Managed storage manifest not found
• with-catch: undefined

Comment 1

[Rob Wu [:robwu]]

The behavior is a consequence of the storage.managed_schema support.
In Chrome, managed_schema describes the supported keys, with fallbacks if any. When the enterprise policy is not set, the keys specified in the schema JSON file (referenced by storage.managed_schema in manifest.json) are used, including their default value if any (EDIT: no default support, and keys are not included).
In Firefox, managed_schema is not supported. The managed storage values are directly taken from the enterprise policy. If it does not exists, an error is raised.

Even if we could silence the errors, extension developers should still be prepared to not have identical behavior between the browsers, until managed_schema is supported (bug 1771731).

---

P.S. The catch vs no-catch in the report is not meaningful.

When a promise rejects, the .catch(() => {}) part is executed. The {} after the arrow function does not denote an object, but the delimiters of the arrow function's body. The following lines are equivalent:

  console.log(await chrome.storage.managed.get().catch(() => {}));
  console.log(await chrome.storage.managed.get().catch(function () {}));
  console.log(await chrome.storage.managed.get().catch(function () { return undefined; }));

Comment 2

[erosman]

When a promise rejects, the .catch(() => {})part is executed. The {} after the arrow function does not denote an object, but the delimiters of the arrow function's body.

The catch in the examples was not meant to return an object {} but to silence the rejection error.

Comment 3

[Rob Wu [:robwu]]

Note: even if if we don't implement validation (bug 1771731), the least we could do is to use storage.managed_schema to provide the keys (and defaults) if any, merged with the enterprise policy-specified defaults.

:zombie stated that Firefox's implementation mirrors the enterprise policy and that my suggestion would result in the inability to detect the absence of the enterprise policy. Both scenarios can be supported: if the extension does not define storage.managed_schema, then Firefox's current behavior can be used. If storage.managed_schema is provided, extension developers would reasonably expect Chrome behavior, and we could close the API compatibility gap there.

In any case, we're not going to make any changes until a consensus has been reached in the WECG at https://github.com/w3c/webextensions/issues/497

Comment 4

[Rob Wu [:robwu]]

Upon testing again, the behavior in Chrome is not as detailed as thought before: Chrome does not provide the keys, let alone the default values.

So the easiest thing we could do for interoperability is to stop reporting errors when the storage manifest is not found.