In the past month I’ve diagnosed and fixed a couple particularly pernicious bugs relating to quirks in IE’s JavaScript. Hopefully if you haven’t run into these before, this will save you some pain in the future.

1. window does not inherit from Object.prototype

Oddly enough, according to the ECMAScript specification, the global window object does not necessarily have to inherit from Object.prototype. In Chrome, FF, and Safari, it does, but in IE it doesn’t.

That means that using something like window.toString.call(foo) will fail in IE, which is exactly what happened to us.

window.toString.call error in IE

So to avoid this problem, just use Object.prototype.toString.call(foo).

> Object.prototype.toString.call({foo: 234});
'[object Object]'

2. Some built-in Functions don’t have apply()

A related problem is that you cannot use apply() on some native functions in IE, e.g. console.log.apply(null, ["foo", "bar", "baz"]).

window.toString.call error in IE

Wait, this is the same error as above. Why? console, like window is what’s known as a “host” object and doesn’t have to inherit from Object.prototype. And since the functions on the host objects are “host” functions, they also don’t have to inherit from Function.prototype.

For more information, check out these two StackOverflow threads:

Bonus: Trivia time (if you’re into that sort of thing):

In the early implementations of JScript – Microsoft’s reverse-engineered version of JavaScript that shipped in early versions of IE – object keys were represented as linked lists in memory, as opposed to hash tables. That means using large objects would cause the performance to be unreasonably slow.