Mozilla Add-On Manager Version Difficulties

2010-11-03

Problem

While developing the Accentuate.us Firefox add-on we ran into a bit of a snag. Our API requires that the user-agent begin with Accentuate.us/version for analytics, random-hit spam prevention, and the ability to handle any future version conflicts. This requires gathering the add-on’s version number, which is specified in install.rdf.

The problem arose when testing Gecko 2 browsers such as Firefox 4, which features a spiffy new add-on manager.

Solution

The solution was rather simple but a little difficult to track down at first, so I’ve included it here for convenience:

1try { // Old addon manager 2 let gExtensionManager = Components.classes[ 3 "@mozilla.org/extensions/manager;1"] 4 .getService(Components.interfaces.nsIExtensionManager); 5 let version = gExtensionManager.getItemForID( 6 "addons-mozilla@accentuate.us").version; 7 Charlifter.Lifter.init(version); 8} catch(err) { // New addon manager 9 Charlifter.Util.log(err); 10 Components.utils.import("resource://gre/modules/AddonManager.jsm"); 11 AddonManager.getAddonByID("addons-mozilla@accentuate.us", 12 function(addon) { Charlifter.Lifter.init(addon.version); } 13 ); 14}

The difference is minor but important. The code in try is for Gecko < 2, which grabs the extension manager from Components.classes. In Gecko > 2, the add-on manager is imported. Once you have the add-on manager object, obtaining the version is trivial.

Relatedly, we had to have the line for initializing the Charlifter (legacy name for Accentuate.us) Lifter object in both places because the version number is needed immediately upon initialization for a language list call, which the callback style of Gecko 2’s add-on manager interferes with.

← all posts

michael schade

I like learning new things. Previously: Kenchi founder, eng & ops teams at Stripe from 2012-2019. Say hi! 🏳️‍🌈