Over in bug 727398 I’m planning on making a change to restartless extensions that could potentially affect addon authors who use the Add-ons Manager API. This only affects code that registers a AddonListener or InstallListener event listener to get notified of add-on and install events, while also interacting with the startup of restartless extensions. I couldn’t find any add-ons on AMO that would be affected by this, but I thought it would be worth blogging about anyway.
Currently, when a restartless extension is installed, it’s startup() function is called before the onInstalled and onInstallEnded events are fired. This meant that a restartless extension would run it’s initialization code before anything else thought it was installed.
However, that causes some issues. For example, if a restartless extension uninstalled itself on startup, then it could be uninstalled before it was installed. Unsurprisingly, the Add-ons Manager UI broke when this happened (since it uses the same APIs that add-ons use).
So bug 727398 will change the order of those operations. When a restartless extension installs, the following will happen in this order:
- The extension’s install() method will be called
- onInstalled event will fire (AddonListener)
- onInstallEnded event will fire (InstallListener)
- The extension’s startup() method will be called
Update: This change will ship in Firefox update 14, which is scheduled to be released on 2012-07-17.
 Why would an addon immediately uninstall itself, you ask? Imagine an add-on whose sole purpose was to flip a preference to disable a newly-shipped but buggy feature, that would get re-enabled on the next application update. This is one of the things that a hotfix add-on could do. Additionally, I’ve been playing with various ideas for restartless extensions as a user support tool – the extension installs, does some work or collects some diagnostic data, then immediately removes itself.