I was just finishing up a Angular.js application. It was then time to test it under Internet Explorer 8 — not for purely masochistic reasons, mind you, but because it’s still the standard browser for some people, including the people for whom this particular app was written.
I’d already tested under Chrome, Firefox, Safari, and IE10, so I wasn’t expecting any problems. There you go. I’ve put it in writing. I’m an idiot.
So IE8 didn’t render the app at all. No error messages. I switched to IE9 to test, and it worked there, unless I put it into “IE8 Standards Mode” when it would silently fail again.
Now, this may not be news to some people, but IE8 really is pretty crappy. I spent several hours tracing through things, which is not easy with Angular.js due to the asynchronous way that most apps are built. This app has services that create Ajax promises and controllers that rely on services. Figuring out what’s supposed to be happening when can be challenging.
To make a long story short, this turned out to be a case of IE8’s non-crappiness. One of the views that was being included had a spurious close div in it. All of the other browsers happily rendered things the way I expected and didn’t even bother to warn me that the HTML was malformed. Only IE8 stuck to the standard and refused to participate in the charade. Yes, you read that right. IE8 was being a stickler for standards. I just don’t even know how to process that fact.
For what it’s worth, it can be hard to find this kind of error. When you have partial views that get included dynamically, and/or they’re ng-templates, it’s hard to see your completed HTML document, much less validate it. I even tried things like the Web Developer plugin’s “View Generated Source” and then submitting it to the W3C Validator to no avail. The way I ended up diagnosing it was the “fire the canon and see what dies” approach of commenting out different chunks of the code until I could isolate the section. From there, it was manual analysis. Yuck.