Why app-global extensions are essentially broken · 2010-08-18 12:44 by Wladimir Palant
Should I rather title this blog post “App-global extensions considered harmful”? I hope not because I see some valid use cases for installing an extension in a central location where it will be taken over regardless of the profile used. However, the current implementation in XULRunner/Firefox has some very nasty side-effects which make using this mechanism a bad choice. And there are apparently many people making the same experience.
For me it all started back when I was working on TomTom HOME. We wanted to move parts of the application into extensions that could be updated independently and earlier than the next release of the full application. The logical choice was to install the extensions along with the application in the application directory. These extensions could then get updates as usually. Updates would be installed into user’s profile and take precedence over the older version in application directory. Sounds like a good plan? As it turned out, it wasn’t:
- An update that has been installed in user’s profile always takes precedence over the version installed in the application directory. This is even true if the version in application directory is newer. So if an application update installed a newer version of the extension in the application directory the user will continue to use the old version if that’s what he has in his user profile.
- What will happen if the user decides to uninstall the extension from his user profile? The application restarts and … Right, the extension is back! This time it is the old version from the application directory which took over.
- Usually the user won’t be able to uninstall extensions which are in the application directory. And it seems that a grayed out “Uninstall” button is very frustrating — even if there is a fully functional “Disable” button.
- Even if the user manages to uninstall the extension, an application update will most likely reinstate it.
But these cases were always few and seem to become even fewer. Usually however extensions are installed globally for other reasons and people hit all the same issues I mentioned above. Which is why Songbird is trying to address the first issue I mentioned (which is a desperate move given that these changes have no chance of being backported to XULRunner). And the third issue forced Microsoft to design their very own way of getting .NET Framework Assistant into user’s profile, causing lots of user confusion. And Skype designed yet another solution, with less confusing but also less stable results.
I filed bug 474289 early in 2009 to do something about this — and I hope to start the discussion on this issue again. IMHO the most promising solution is having “default extensions”, located either in the application directory or in a location pointed to from Windows registry. When the add-on manager sees a new extension in one of these locations it should install it into user’s profile. And at that point it should behave like any regular extension with an option to disable or uninstall it. I think it is also important to remember extensions that the user uninstalled so that they won’t be installed automatically any more.
Any thoughts? Comments? Anybody willing to start writing patches?
Commenting is closed for this article.