I’ve been using Firefox for a long time. I started way many years ago with version 0.5, when it was named Phoenix and tabbed browsing was still a huge deal. Over the years, I’ve accumulated a lot of plug-ins that I add to any Firefox installation. Some of which, I just can’t function without.

Currently I’ve got 25 installed plug-ins. Some haven’t been updated since I first installed them years ago. Others seem to be updated weekly. With so many plug-ins updating on their own schedule, I find myself faced with the plug-in update dialog at least 2 or 3 times each week. Firefox has the annoying habit of prompting for updates on start up if the previous session has detected pending updates to installed plug-ins. The worst part is that Firefox will halt the start up process until either I’ve ignored the updates, or the update has completed. I’ve come to call this behaviour Update Paralysis.

Update Paralysis isn’t limited to Firefox or its plug-ins. I haven’t really noticed it with other applications until I sat down to write this post, but it appears to plagues just about every application that checks for updates. Just no where near as frequently. Even those with their own task-bar bound update widgets.

Too often, I’ll start Firefox, or any other number of applications, with a specific task in mind, and then get distracted to the point of forgetting about the task by the time the update paralysis has subsided. With today’s internet speeds the entire process usually takes no more than a couple of minutes at worst, but it’s still an unnecessary interruption, and enough to cause my mind to wander.

Most of these programs check for updates at startup. Some will tease you by loading the application and disabling it until the update paralysis is satisfied. So I started thinking, what’s wrong with waiting until the session ends to install. In the case of Firefox, I’m thinking along the lines of triggering the update dialog as the last tab is closed. Post session updates will still take the same amount of time, and the application will still need to restart. However, with the update happening in the background after I’ve finished my session, I don’t care how long it takes because it’s not stopping me from completing the task at hand. Double bonus: with the restart action spread over the minutes/hours/days that go by before my next session, I’m not going to notice it.

This is a practice that, for the most part, needs to disappear. Critical Security Fixes should definitely cause update paralysis and should remain an exception. But all other updates should be done as unobtrusively as possible.

Thankfully update paralysis only effects a handful of applications I use. I believe the only reason I haven’t noticed it sooner is that 99% of the software I use, and update, come from the repositories of my current Linux distribution. These applications don’t check for updates. That’s the package manager’s job.

Speaking of the package manger, update widgets are another solution to update paralysis. But it’s only really a viable solution on Linux, where all application and system updates are collected for retrieval from the a single trusted source. In the Windows world, many vendors distribute their own update manager that check for and install updates for packages they provide. Given, that it’s nearly impossible to have a useful computer using only software from a single vendor. Relying on multiple update managers to get the job done is justtrading update paralysis for other problems.

In the case of Firefox, There is this bug report/feature request, but that doesn’t mean it ever get changed. Odds are I’ll end up patching it myself during some insomnia time.