Man! Have I been at war with IE lately. I have been holding back a lot of blog posts related to debug IE problems, and I going to start spewing them out now one by one. For the first installment I'll talk about one I encountered these couple of days...

Ever get this IE error?
When you click "Ok", this is what you see:

Ouch! Can this be any more catastrophic?(Yeah, that's my Chandler impression.)

According to this forum post, this happens if you have script tags in your document that's modifying other parts of the dom before the document finishes loading. Umm, okay, but I still had a hard time finding out the exact point this caused the problem. I used the comment-out-code-and-see-if-it-still-breaks-binary-search methodology, and came up with some work arounds which involved delaying the execution of some setup code. But, this catastrophic error came back to haunt be time and time again. Clearly I didn't find the root cause of this error or I wouldn't be committing it repeatedly.

But finally, I found it(I think, well at least one of the root causes). I am using firebug lite in development, which creates iframes and panels in the pages that pops out and in just like firebug. When you call console.log with firebug lite, guess what happens? Yeah, it modifies the console output window - a part of the dom that is outside of where the script tag is. Got rid of those console.log statements and fixed it.

In conclusion, do not do what I did!

IE, are you kidding me?

If you register the change event for a radio button, they fire at different times between IE and FF. FF fires the event immediately when you click on the radio button to change its value. IE does not, it fires changed only when you blur the element.

If you write an input element like this:
<input type="text" id="name" name="name" value="></input>
In IE, if you try to traverse the dom, you will get the end-tag as a separate element /input. Ex. with prototype: $('name').next() should get you /input.

If you use a button element as a submit button in a form, like:
<button id="mybutton">My Button</button>
$('mybutton').value in FF will get you an empty string whereas in IE you would get "My Button"

Since Chrome is so great, I wanted to use it for all my browser needs. But the apps I've been working on myself have not been targeted for WebKit - the rendering engine used by chrome, and also used my Safari. This is mostly due to laziness on my part - having to handle two browsers at a time is chaos enough. But Safari compatibility is on my todo list for more than one of my projects, and chrome is a good push for this cause. And so I went in today and made just todo list. compatible with Chrome and Safari. The differences I encountered were:

1. This is really prototype specific - prototype adds an empty underscore parameter for all Ajax request for WebKit browsers. Because apparently, Safari errors out when you try to post with an empty body on XHR calls. And, who knows, this might already be fixed in WebKit. I happened to have code that was not handling this fact on the server side. This was no biggy.
2. This is an error on my part really, but I had a form with a text input inside. But also registered for the key events on the text input so that when enter is pressed I called form.submit(). The key event code is really unnecessary because an enter on the text input triggers the form submit on both FF and IE. So, although on the other 2 browsers this was no problem, in WebKit this triggers 2 posts. So... just DON'T do this.
   

function.toString() has different behavior between IE and FF. FF collapses the parameter list onto one line, while IE leaves it untouched. Ex:
function f(
  param1,
  param2,
  param3){
  ...
}

f.toString();
In FF you would get something like:
function(param1, param2, param3){
...
}
in IE:
function f(
  param1,
  param2,
  param3){
...
}

In IE, this breaks function.argumentNames() in prototype.js, so don't break the parameter list into multiple lines if you are using prototype.js, or until they fix it. Also, notice that FF removes the name of the function in the toString() output.

If you use the button element, make sure you set the type attribute:
<button type="submit">Submit</button>

Otherwise, it won't submit it's parent form when clicked in IE.

I haven't dug down to the bottom of this but basically Element.descendantOf(elm, ans) gives different results from IE vs FF.

Wow, FF3 broke my app!

I had a line like this(sorry this code uses prototype.js, but it's not specific to it):
myDiv.setStyle({
    position: 'absolute',
    top: elmPos.top + elm.offsetHeight,
    left: elmPos.left,
    width: elm.offsetWidth - 5});

This won't work anymore because starting FF3, you can't set the attributes: top, left, width, height to numeric values anymore, they have to labeled with a unit, like so:
myDiv.setStyle({
    position: 'absolute',
    top: asPx(elmPos.top + elm.offsetHeight),
    left: asPx(elmPos.left),
    width: asPx(elm.offsetWidth - 5)});

Where asPx is:
function asPx(n){
    return n + 'px';
}

This behaves differently on FF vs IE. If you do:

textInput.value = "line one\nline two";

Where textInput is an input element with type="text". FF ignores the second line and sets the value to the contents of the first line, whereas IE removes the newlines and merges all the lines into one.

With prototype.js, you should use element.up() instead of element.parentNode. This is again because of this browser difference.