A common usage pattern for the Add-ons Manager API is for an add-on to fetch its own Addon object, for the sole purpose of getting it's version. That saves the developers needing to keep a version string updated in multiple places, and it's useful for detecting upgrades, displaying the version in the UI, etc. However, doing that requires database access. If an add-on is doing that on startup, then we're always opening the database on startup - which comes with a startup performance cost. Also, its just a needless complex async API just to get a version string. For that use-case, we could provide a simple sync API: AddonManager.getAddonVersion(aID); XPIProvider can use extensions.installCache to find the installed version. I think all the other providers can already do this synchronously (not that I've seen any need in the wild for other providers to support that).

Er, for a moment I thought extensions.installCache included the version - of course it doesn't. But extensions.enabledAddons and extensions.bootstrappedAddons do! And this is the 2nd reason to convert extensions.enabledAddons to store JSON, the other being bug 791987. Filed bug 793143 for that.

A related use case for this is something I see AdBlock Plus doing - ABP modifies its behaviour depending on whether you have another addon installed, so it queries AddonManager looking for that other addon during initialization.

The use case presented here doesn't apply for webextensions (they can use something like browser.runtime.getManifest() ) For internal use, we have AddonManager.getActiveAddons() which doesn't cover this exactly but I don't think there's much point keeping this bug open.