At Fi we are very experienced at making sites that both support modern features like HTML5 or WebGL, but also that degrade gracefully for older browsers. Sometimes we come across very unusual behaviors, often related to the fact that our sites push the boundaries of what browsers are capable of. Recently I came across a really hard-to-spot, one-time-in-a-million bug which affects older versions of Internet Explorer.
Most developers have come across the Operation Aborted error. It comes about when you attempt to change an element before Internet Explorer has had chance to read it in its entirety. The classic case of this is when you use JavaScript to embed a Flash movie (rewriting the HTML elements in the process) inline. This is one reason among many why it’s worth putting your JavaScript files to the end of your pages.
So there I am testing a page in Internet Explorer 7 when I get the Operation Aborted error. Naturally I assume it’s a JavaScript bug, something is prematurely modifying the HTML, and IE is upset about it. I begin the Binary Debugging Method (delete half of your code and test. If the error still occurs, delete half of what remains and repeat until the bug is located) to see if I can find where it’s coming from. Eventually I still have the bug, but there’s no JavaScript left on the page. This shouldn’t be happening since JavaScript is needed to cause the Operation Aborted error. I’ve been making websites for a long time, so I’m pretty sure someone has changed the Internet while I wasn’t looking.
Both of these are critical when you hit a massive bug. Search on Google and, if that yields nothing, start calling over your colleagues. Never fight a problem for more than fifteen minutes! Between these brains we should be able to find a solution. Well, after many, many hours and cups of coffee I’ve tried everything I can think of, and I’ve reduced the page to five lines or so of HTML and I’m still getting the error. And I’m even seeing it in IE8, which apparently isn’t even technically possible. News for you: it is!
The Solution
After a few tweets and a lot of further head scratching we fired up the page in IE9 rendering as IE7 to see what happened. There was a warning about charsets, about how IE is resetting the encoding of the page to UTF-8 from Windows-1252 (its default encoding). IE9 doesn’t crash or make a fanfare about this, and it’d be easy to overlook. However, having seen that I went to the site’s Apache configuration and added the line: AddDefaultCharset UTF-8, that’s all it took to fix the problem. My theory is that, in the absence of a default character encoding, IE set about rendering the page using its default, but when it reached the line in the HTML telling it to go to UTF-8 it wasn’t able to handle it and crashed. By having Apache start the page in UTF-8, when IE reached that one line it no longer needed to change anything at all! For me and the team, getting to that one line took a lot of deductive reasoning and, mostly, a world of determination and perseverance. And that’s how we do what we do; we keep going until we hit the solution.
How about you? Do you have the drive to find and fix the problems other developers would give up on? If so, maybe you should apply to join our world-class team of developers.
Paul Lewis
Senior Application Developer
Fi Stockholm
Found this problem out before finding this blog. We only found so quickly because I had a different Apache config to my colleagues and it contained AddDefaultCharset. There are many red herrings out there, none of which suggest it could be an HTTP header problem. Like you say, the only way to get to the bottom of it is to be ultra-thorough. Or get lucky like we did!