Inconsistency: runtime.getManifest() and missing keys

[bershanskiy]

Background

runtime.getManifest() lets extensions to retrieve their own manifest.json contents (Chrome docs, MDN). At least in principle, since the retrieved data structure is actually a result of export of browser-internal data structure generated from manifest.json and other sources. This ticket aims to clarify the differences and reconciliate them.

Details

Availability

runtime.getManifest() availability in different contexts differs across browsers. In Chromium and Firefox, chrome.runtime.getManifest() exists in content script contexts, but in Safari it does not.

Using null or undefined for empty fields

Chromium and Safari use missing values (which do not appear in Object.keys() list and evaluate to undefined). Firefox uses null.

Manifest current_locale member

Chromium adds current_locale to manifest. Firefox does not. Safari 16.5 does not.

Manifest update_url

Chromium seemingly hides update_url.

Other differences?

[tophf]

Adding an example for an "empty field" and a "missing value" would be helpful as these aren't precise terms in extensions/JS.

[oliverdunk]

I spoke to @rdcronin about this. We are generally aligned that chrome.runtime.getManifest() should return the browser's parsed version of the manifest including any extra fields added during distribution such as update_url. In Chrome, we also return it after any keys using the __MSG format have been localized. It would be interesting to know if other browsers do the same.

In Chromium and Firefox, chrome.runtime.getManifest() exists in content script contexts, but in Safari it does not.

This matches our expectation, and we don't plan to remove this API from content scripts.

Using null or undefined for empty fields

I'm not certain what is meant here. Is it just that fields not specified by the developer aren't included?

Manifest current_locale member

This is an implementation detail, and part of how we store which language we have localized the manifest (and fields like name) to. It shouldn't be returned and we need to filter this out - great spot. I've filed a bug: https://issues.chromium.org/350350583

Chromium seemingly hides update_url.

I wasn't able to reproduce this - are you still seeing it?

[xeenon]

Safari also localizes the result, so you should not see any __MSG values.

[fregante]

I recently found out that Firefox does not return the manifest verbatim but it drops anything it doesn't support, that includes any items in the permissions array. An example is "contextMenus" on Firefox Android. Safari iOS limits itself to leaving browser.contextMenus undefined, but Firefox removes all mentions from the manifest too.

[carlosjeurissen]

@oliverdunk Seems the current_locale property of chrome.runtime.getManifest() always returns the equivalent locale given by chrome.i18n.getMessage('@@ui_locale'), even if the extension is not localised in said language. So this property seems pretty useless in it's current form. @hanguokai this might be relevant for #641.

[hanguokai]

@hanguokai this might be relevant for #641.

Oliver has replied to current_locale before. He said "it shouldn't be returned". I also think so, because it does not exist in the manifest file.

Back to this issue itself, there are some inconsistencies due to the lack of specifications. However, from a developer's perspective, I don't know of any real-world cases where developers have to rely on this method. Basically, manifest is just static data.

In the meeting note, @bershanskiy said "Sometimes it's convenient to use this as feature detection for support of manifest keys.". If so, I think it would be better to provide a new method for it, such as runtime.support().

[birtles]

Another difference is that Safari appears to append the unique install ID to the end of manifest.version.