I noticed that TableKit‘s sort performance using IE7 grew progressively worse as tables grew in size (rows, not columns). I found the source of the problem and put in a simple fix to it. With the below change, sorting in IE7 is nearly as fast as in Firefox — that is, nearly instantaneous.

At line 322 (TableKit 1.2.1), comment the line as shown, and add the line noted.
var tb = table.tBodies[0];
var tkr = TableKit.Rows;
rows.each(function(r,i) {
tb.appendChild(r);
//tkr.addStripeClass(table,r,i); /* THIS LINE COMMENTED */
});
TableKit.Rows.stripe(table); /* THIS LINE ADDED */
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: . . .

→ Read More: Improving TableKit’s sort performance in IE7

I have a web application that allows the user to press the F2 key to bring up a modal box search window (the modal box script is provided by ModalBox). Today, one of the users came to me and said that every time they press the ‘Q’ key in the search box, the modal box refreshes.

It turned out that pressing the ‘Q’ key did in fact refresh the modal box — but only in Firefox, not in Internet Explorer. Knowing that Mozilla and IE have slightly different JavaScript event capture techniques, I looked at the code I was using to capture the F2 keypress.

Event.observe(window, 'load', function() {
Event.observe(
document, 'keypress', function(event)
{
if (event.keyCode)
keycode=event.keyCode;
else
keycode=event.which;
if (keycode==113)
Modalbox.show('Search', '/search/quicksearch.rails', {width:360, height:90});
}
);
});

A little research and I found the problem: keyCode 113 is the ASCII code for the lower-case ‘q’. I needed to find a way to capture the event when the function key 113 was pressed, not the ‘q’ key 113.

The solution was to use the event.charCode exposed . . .

→ Read More: Capturing function keys in web browsers