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.

Let's say you have markup like follows:
<div id="foo">
        <div id="bar">hey</div>
</div>
In IE, document.getElementById('foo').childNodes.length gives you 1, but FF gives you 3, with the first and last items being text elements representing the newline and white space in between. This means you cannot rely on accessing childNodes directly by index.

Solution:
If you are using prototype.js, use firstDescendant() instead of childNodes[0]. Use select() to get select the elements you want instead of traversing childNodes directly.

FF has a built-in Element "class". Which means that you can extend it like this:
Element.prototype.mymethod = function(){
  //blah
}
and have the method be available from any dom element, no prototype.js needed.
document.getElementById('myDiv').mymethod();
This is what explains this previous post.