Proposal: `runtime.getVersion()` method

[oliverdunk]

We should add a new method to get the installed version of an extension:

getVersion(): string

Today, there is significant usage of runtime.getManifest().version as an analogue to this.

By adding a new method:

• In the short term, this simplifies getting this data, and makes it easier to see usage in static analysis.
• Longer term, this may reduce usage of getManifest() and allow us to deprecate it or limit availability to certain contexts. This is desirable as the behavior is poorly defined - see Inconsistency: runtime.getManifest() and missing keys #400.

Availability:

Trusted extension contexts and content scripts.

This matches getManifest() since there is significant usage in both contexts.

This API is still synchronous to encourage adoption as an alternative to the synchronous getManifest().

[oliverdunk]

It seemed like there was general support of this in the last meeting, but it would be great to confirm here. One notable detail is the suggestion to not make this available in content scripts.

cc/ @Rob--W @zombie from Firefox and @xeenon @kiaraarose from Safari.

[fregante]

Unlike getManifest(), this should not be available in content scripts

This would kill the usage of the API and people would stick to getManifest. There's no advantage in using the new API if you add this limit

[oliverdunk]

This would kill the usage of the API and people would stick to getManifest. There's no advantage in using the new API if you add this limit

Could you share your use case? I would have expected this to be mostly needed in background scripts and extension pages.

[fregante]

I'm just not generally a fan of restricting data to certain contexts, it makes things difficult. This piece of information has been available everywhere for 15 years; a new API is being introduced with reduced capability for something as basic as a version (which browsers themselves have exposed to the whole web for 30 years via UA)

[oliverdunk]

I'm just not generally a fan of restricting data to certain contexts, it makes things difficult.

We shouldn't expose APIs in content scripts without concrete use cases. It is easy to expand availability over time but once we have made an API available, it is hard to take away.

That said, I took a look at usage of getManifest() in the Chrome Web Store and I saw more usages in content scripts than I expected. With that in mind, I think there is a good argument for exposing getVersion() there too. I've updated the proposal.

[oliverdunk]

Chromium issue: https://issues.chromium.org/448473578

[xeenon]

WebKit issue: https://webkit.org/b/299961

[gorhill]

A reminder that there are currently two version-related entries in the manifest, version and versionName.