OK, so I’ve been slowly rotating my Windows 7 PCs (of which I currently have 7 at my disposal) from IE 8 to IE 9, thanks mostly to the elevation in status at Windows Update from optional, manual update to automatic or pushed update. By and large, this transition has gone reasonably well, but I do still have some gotchas with WordPress to contend with (I blog 40-plus times per month, of which only 4 or 5 posts occur outside the nearly-ubiquitous WordPress umbrella — in fact, I’m writing this very blog using WordPress right now).
I’m also writing it using Chrome 11.0.696.60, because IE 9 remains unusable with this software. Why? Simply put, the cursor based button controls don’t work, and thus I can’t insert hyperlinks into my posts unless I decide to edit the HTML by hand (insert explicit <a href=”link” …> markup myself, in other words — not gonna happen: I *like* automation). So while I’m waiting for the powers that be to figure out what’s up and how to fix it, I’m using Chrome. And I must say, it’s doing its job quite nicely.
But the other day, when I applied the most recent Patch Tuesday updates to a machine that had been sitting idle for a while, I found myself in an infinite loop situation with IE 9. When you install a new IE version over an old one (this time it was going from IE 8 to IE 9), it copies the old preferences, favorites, and other settings from the old version to the new as part of the upgrade. I’m loaning out my old HP “Dragon” to a pool-playing buddy and I was updating that machine to the latest and greatest of everything. But when that process completed, and I tried to run IE 9 for the first time, something about tht install caused the browser to crash every time it tried to load the default home page for the Google search engine at www.google.com.
IE 9 tries to automatically recover when such things happen, so it closed the open (and only window), then tried to reload the Google page again, only to crash again. Repeat ad infinitum, and ad nauseum. The only way I was able to stop the madness was to jump into task manager and kill all active iexplore.exe processes.
Fixing the problem required some interesting contortions, too. I had to jump onto another machine and download a standalone browser installer for the Dragon because it had no working Web browser installed (IE 9 remained hosed, and I had just cleaned all the extraneous software off that machine for my buddy, so he could gunk it up however he chose). I couldn’t get the Chrome standalone installer to work on that machine, so I ended up using Opera instead. It let me visit the Microsoft Download Center where I grabbed a clean download for 64- and 32-bit IE 9, believing that something was wrong with the install that Windows Update left on my machine.
However, Windows detected that IE 9 was already installed on my PC, and wouldn’t let me install the older Download Center version on top of the newer but non-operational version. So I had to go into the Programs and Features widget in control panel, then use the “Turn Windows features on or off” to disable IE 9. After a reboot, I was then able to successfully install the Download Center version, and re-apply the now-missing updates from Windows Update between the release of the initial version and its current state. No more issues with loading the Google search page, and finally back to IE 9 status quo, such as it is.
My point here is that you are still likely to encounter the occasional gotcha with IE 9 in your users’ desktop environments. I have to agree with Windows mavens like Ed Bott and Paul Thurrott, both of whom still recommend that enterprises hold off on IE 9 upgrades until the program settles down a bit more, and gets additional bugs shaken out. At the very least, you’ll want to test your user runtime environments long and hard, and make sure IE 9 survives those tests gotcha-free, before inflicting the latest Internet Explorer version on your user community. Otherwise, you’ll just wind up making more work for yourself in the long run (and for your hapless help desk counterparts).