internet-explorer document.title - What are the common mistakes to avoid when coding javascript for Internet Explorer?

w3schools get (12)

Watch out for little differences like the way iframe borders are handled (How to Remove an IFrame border in Javascript).

I guess the internet-explorer tag should give you lots of good examples.

I'm about to start coding a new, javascript-heavy website, but before I start I'd like to minimize my debugging time in Internet Explorer by knowing beforehand what the quirks are. I'm not planning to worry too much about IE6.

What are the common mistakes/differences to avoid in javascript code that work fine in other browsers, but break in Internet Explorer?

The most common mistake while writing a site that has to support IE is to forget to test in every version.

You need to make sure all your code works in IE6 (if you plan to support it), IE7, IE8, and IE8-in-IE7-mode. And also IE9 (which is now in beta).

There area few shortcuts to testing multiple versions of IE, but be aware that they don't always give exactly the same results as what real users will see; the only way to be sure is to actually test it in real versions of IE, no matter how painful that is.

IE does not support custom events, only DOM events (yes even in 9 beta).

Be aware of how Internet Explorer handles dom tree parsing and navigation, one in particular, that also exists when parsing httpObjects in general :

  • xmlNode.textContent does not return anything in internet explorer
  • xmlNode.firstChild.nodeValue or something that returns the node value must be used


Use a framework like jQuery or Prototype and you will not need to worry about it.


I should clarify. You will have a lot less to worry about. Such as:

  • ActiveXObject vs XMLHttpRequest
  • attachEvent vs addEventListener

List item-

IE 7/8 fails to understand console.log/dir unless console window opened. This can easily break your JS if you leave any in the prod environment. Always have

   console.log('Hello World')

If you assign an event handler directly via javascript, event will not be provided automatically.

myElement.onclick = function(e) {
    alert(typeof e); // undefined

the workaround is to pull window.event.

myElement.onclick = function(e) {
    e = e || window.event;
    alert(typeof e); // this is ok now

if you're an event handler directly on the element, you can provide the event reference manually.

<input type="text" onclick="myMethod(event);"></input>

this is cross browser and is fine, if you have to go that route.

using attachEvent to set an event handler provides the event object as a parameter to the method automatically.

Here's a subtle one: if your site has multiple frames (or iframes), and you've got Javascript code communicating between frames sometimes, IE (6 and 7, not so sure about 8 and 9) is very picky about the "lineage" of Javascript objects, even ones without any DOM references. What that means is that if you communicate a Javascript object of almost any type (strings and numbers are usually OK, but even Date instances have caused me problems in the past) from one frame to another, if at some point later the source frame is updated with a new page, the destination page will get an exception if it tries to mess with that communicated object. Firefox was pretty mellow about that sort of thing, but when IE garbage collects the old page, it thereafter does not like references to the Javascript objects that page created.

IE (8 and lower, not sure about 9) cannot handle accessing characters in strings like arrays, as in:

var str = 'abc';
var c = str[2];

In most browsers this will alert 'c', but IE alerts 'undefined'. For cross-browser reasons one should rather use the charAt function:

var str = 'abc';
var c = str.charAt(2);

This will alert 'c' in IE as well.

Another small difference is that of the trailing comma in objects and arrays. This is valid in most browsers, but raises errors in IE:

ar = [1,2,3,]

and also

ob = {name:'janet', surname:'walker',}

which can be quite irritating if you're not aware of it. Both these problems are probably something I run in frequently because I'm used to python, but it's still worth looking out for.

Internet Explorer.

Ok more seriously, the trailing comma answer in another answer is good. Using a framework can help, but its not a catch-all. You are going to have to deal with cross browser issues. So make sure you test in all versions you care about.

IE's JS engine, prior to IE9, is slow. Really, really slow. Hundreds to thousands of times slower than the Mozilla and Webkit implementations.

This shows up in the minimum resolution of animation timers, the time to complete sorts and (as @some pointed out) bogus string concatenation, and anywhere else where your site's performance is bounded by the speed of the JS engine itself.

There are already some very great answers but I'm posting a new one to emphasize my observation on case III below about what happens when you have an explicit return statement in a function which you are newing up. Have a look at below cases:

Case I:

var Foo = function(){
  this.A = 1; 
  this.B = 2;
console.log(Foo()); //prints undefined
console.log(window.A); //prints 1

Above is a plain case of calling the anonymous function pointed by Foo. When you call this function it returns undefined. Since there is no explicit return statement so JavaScript interpreter forcefully inserts a return undefined; statement in the end of the function. Here window is the invocation object (contextual this) which gets new A and B properties.

Case II:

var Foo = function(){
  this.A = 1;
  this.B = 2;
var bar = new Foo();
console.log(bar()); //illegal isn't pointing to a function but an object
console.log(bar.A); //prints 1

Here JavaScript interpreter seeing the new keyword creates a new object which acts as the invocation object (contextual this) of anonymous function pointed by Foo. In this case A and B become properties on the newly created object (in place of window object). Since you don't have any explicit return statement so JavaScript interpreter forcefully inserts a return statement to return the new object created due to usage of new keyword.

Case III:

var Foo = function(){
  this.A = 1;
  this.B = 2;
  return {C:20,D:30}; 
var bar = new Foo();
console.log(bar.C);//prints 20
console.log(bar.A); //prints undefined. bar is not pointing to the object which got created due to new keyword.

Here again JavaScript interpreter seeing the new keyword creates a new object which acts as the invocation object (contextual this) of anonymous function pointed by Foo. Again, A and B become properties on the newly created object. But this time you have an explicit return statement so JavaScript interpreter will not do anything of its own.

The thing to note in case III is that the object being created due to new keyword got lost from your radar. bar is actually pointing to a completely different object which is not the one which JavaScript interpreter created due to new keyword.

javascript internet-explorer