Forcing IE8 Compatibility Mode in IIS

When I saw IE8 being pushed out via Windows Update I was ecstatic. This meant that in a few months the number of installations of the first semi-standards compliant browser made by Microsoft will reach a critical mass. At that point I will be finally able to stop supporting IE6 on some of our web apps. Or rather I will be fairly justified for beating people up for not upgrading their browsers.

IE8 is the current version that was automatically installed on the company computers via Windows update. IE7 is the obsolete, outdated version that was replaced by IE8. IE6 is an 8 year old blast from the past. Anyone still running it is probably using a private computer, on which they are obviously not keeping updated, and which may be riddled with trojans and keyloggers. Considering that we have to write custom css, and javascript code to work in that dinosaur, which is costing many man-hours (and probably some woman-hours as well) should we support it for our internal web apps?

At this point most managers will agree that it probably doesn’t make sense to waste time learning IE6 specific hacks anymore. They might still want to support “the previous version” just in case. Up until now, that version was IE6. Now it’s IE7. Whee!

Internet facing stuff will probably still need to be hacked for IE6 but internal stuff that is only used by the staff can now be free of the nightmarish “oh, wait – how do we degrade this gracefully in IE6” phase which usually ends up taking 80% total development and testing time. Instead we can just put little passive aggressive notes on our websites that say something along the lines “Why are you accessing this website with an insecure obsolete browser? Click here to upgrade”

The excitement was short lived of course, IE8 support tickets started piling up. Most of these said something like “Users computer freezes while filling out the time sheet” or “User loses internet connectivity after logging into the time sheet system”. It doesn’t sound like and IE issue, does it. At least not on the surface. That’s because you are not thinking like a user.

What was happening is this: the 3rd party online time sheet system we were using was not IE8 ready. Or if an IE8 patch existed, was held up somewhere at our end due to the classic “well, can’t you patch the production server when we are not using it – like at 3am on Christmas Eve – but call Bob and his team before you do anything, because they might be using it even then” issue.

Either way, the “clever” Javascript it uses for redirecting and setting up pages somehow managed to cause IE8 to freak out and go into some very resource intensive infinite loop. The users would see a blank page, and the browser would simply stop responding and wouldn’t close unless killed via the task manager. This would happen just after logging into the time sheet system and only on IE8.

For a lot of our users IE == Internet so they interpreted this problem as network connectivity issue or a general system failure. A lot of people don’t even know you can kill processes via Task Manager so they would automatically reboot their system when this happened. And thus we started collecting all these weird tickets that hinted at wide variety of falsely perceived symptoms.

Users who preferred Firefox did not report this issue. Neither did people working from home their personal computers with IE6 and IE7. It was a unique IE8 centric bug and it needed to get fixed. Quick investigation confirmed that enabling the IE Compatibility Mode prior to logging in would work as a workaround.

We briefly considered sending out a memmo about this but the help desk informed us that several users literally broke into tears when they were told they needed to press an additional button before logging in. One person claimed that he will need an extension on his report because of this “inconvenience”. Several people simply said they will not input their time sheets until the matter is resolved because the workaround is too confusing. Someone also threatened to quit the job over this. Of course we got that person an intensive 20 minute in-person, hands-on training with several of the IT people and in the end he decided it was actually a fairly easy workaround.

Needless to say, we needed a better solution than trying to train our users. It’s sad but these people react to knowledge the same way most people react to the smell of a freshly ripped fart – they make a face, and try to excuse themselves and leave the room as soon as possible. Which makes me wonder how do they acquire the much needed on-the-job skills such as using Excel formulas and such… Oh wait… Never mind, they use pre-made templates with formulas already entered in, and when they need to add/remove rows, create totals or do anything out of the ordinary they call the help desk.

“What if we just put that stupid meta tag in the header” someone suggested. Of course that would involve digging through the mountain of outside code that constituted the time sheet app. It was something no one really wanted to do. So yeah… Trying to teach them something new seemed to be a lost cause.

Fortunately there is a better way. You can force the compatibility mode by sending a special header to the browser. In IIS you can do it by going to the properties dialog for your website and adding it on the HTTP Headers tab:

Add a Custom Header

Simply click on the button and type in X-UA-Compatible as the header name, and IE=7 as the value:

X-UA-Compatible: IE=7

This will globally force the compatibility mode for the whole site. Users won’t even see that silly little button, and the pages will render in the IE7 mode. This method is much better than the meta-tag because it can be easily removed on the fly without ever touching the code. And of course it is much easier to deploy than pushing out some custom settings to all your users.

If you ever need to do this, here is how. I hope you won’t ever have to resort to this method for the code you write. If you do, it means that you are clearly doing something very, very wrong.