Javascript Madness: Introduction

Introduction

In the course of the development of the Web Paint-by-Number site and various other heavy-duty Javascript applications, I've found it necessary to do a lot of experimentation with different browsers to figure out how they handle different things. The results have generally been nightmarish, with truly impressive ranges of bizarre and strange behavior.

These pages summarize my results in a few areas, mainly having to do with event handling. I wrote them up largely for my own future reference. I have found very little of this information available elsewhere on the web.

Ideally, we would be able to write single Javascript programs that would work on all browsers. In practice, this is only possible if you are willing give up a lot of functionality. Many of the features used in the Web Paint-by-Number site would have been impossible in implement without first sensing the browser type and then selecting different code to run for different browsers, or different versions of the same browser. Sad, but true.

Worse, due to bad design and shear bugginess, there are perfectly simple things that cannot be reliably done on some browsers, like identifying with certainty which key was pressed to trigger a keydown event or recognizing when the second click of a double-click occurs.

If you are a programmer trying to sort these things out, you might consider adopting one of the freely available Javascript toolkits on the web. Some of them can help insulate you from this kind of low-level headaches described in this page. Surveying such toolkits is beyond the scope of these pages, however. I recommend that you google "Javascript toolkit" and see what you find.

Contents

Mouse Events

Madness in the handling of mouse events. Which events are fired when you click or double-click with the left, right or middle mouse button on various browsers.

Key Events

Madness in the handling of keyboard events. Which events are fired when you hit or release a key or allow it to auto-repeat in various browsers. The demented strangeness of key codes which may or may not identify which key was hit.

Dynamic Script Loading

A study of a method of loading additional Javascript functions on demand after the rest of the page has already been loaded. As usual, many browser incompatibilities are discovered.

The Javascript Sleep Deficiency

Does Javascript have some equivalent to the sleep() function that other languages use to pause execution for a bit? Yes, it can be done, but only horribly.

Treacherous Type Conversions

A (hopefully informative) rant about string/number type conversions in Javascript.

Layout Engines and Gecko Versions

Why I talk about "Gecko" instead of "Firefox" in the above notes. Which versions of Gecko are used by various browsers and a few notes on other layout engines.

KISS Javascript Compression

Some thoughts on compressing Javascript code.

Ill Informed Grousing About Browsers

These tests have done little to raise the various browsers in my esteem. I'm sure most everyone is trying very hard and the task is very difficult, but the results, from where I sit as a web application developer, aren't very impressive.

Internet Explorer

Seriously old fashioned and hardly compliant to standards. Microsoft, out of selfless devotion to backwards compatibility, trained IE 6 and 7 to lovingly emulate all the miserable bugs from IE 5, unless the web page author begged them not to, in which case they run in a slightly less buggy mode. With the recent IE 8 release, they fixed enough bugs and made enough other improvements to close about half the distance between them and all the good browsers, so they introduced yet another backwards compatibility mode, so it can now emulate either IE 5 bugs or IE 7 bugs. Of course, there are bugs in these bug emulations, where some bugs don't work exactly the same way they did in the original buggy browser, but the IE developers are working themselves buggy to fix all these buggy bugs. With so much time devoted to making their browser work wrong, it's hardly surprising that they can't also find the time to make it work right. So it's left to the world's web developers to work around all of IE's bugs so that IE users can persist in the illusion that they are using a functional web browser. I guess we must all love Microsoft, or we wouldn't do it.

Firefox and other Gecko Browsers

Much more standards compliant than IE. It may be true that all bugs are shallow to many eyes, but many eyes seem to make danged slow progress. This means that some lesser bugs often don't get fixed for years after they have been reported, but it has a good side too. Though there are many open source browser projects, few work as openly and with as much transparency as the Mozilla team does. The Mozilla developers never seem to participate in the races to be the first and the fastest that periodically break out between the Safari and Opera teams. So though they aren't always leading the pack, their more deliberate and methodical pace seems to lead them to make fewer of the hasty missteps made by others. When Mozilla releases a new browser, I don't expect to see as many exciting changes as in a new Opera or Safari, but I don't expect to see major new bugs introduced either.

Safari and other WebKit Browsers

This used to be the browser that causes me the least headaches. If you wrote code to work on IE and Firefox, then it pretty much always worked on Safari. Up through version 3.0 there were lots of signs of very careful thought going into their design choices, clear attempts to balance compatibility with sanity. In terms of compatibility and correctness, Safari seemed to have overtaken everything else. Recently, however, their competitive exuberance has occasionally been getting the best of them. For example, they greatly hyped their new faster regular expressions, but they weren't always as fast as the hype suggested and they were sufficiently buggy that I had to entirely rewrite my most complex regex application not to use regular expressions anymore. This hasty, benchmark-driven development style, this race to be first and fastest, risks undermining an otherwise terrific browser.

Opera

This is the browser that has caused me the most headaches. While Mozilla's developers seem mired in bureaucracy, and Microsoft's developers are only just finding their desks again after a seven year vacation, Opera's developers have always been speedy and nimble. Every release is different from the last. Old bugs turn into different bugs, new bugs are introduced, and sometimes a bug is even fixed. Every bug I ever reported to them was changed in a subsequent release, though only one of them was ever actually fixed. Some behavior is subtly wonky. I sometimes wish they would slow down and figure out how things are supposed to work instead of patching patches. I strongly suspect their event handling code needs to be thrown out and re-written from scratch if it's ever going to really be correct. As it is, tracking what does and does not work in Opera is a constant headache, and there has always been enough non-working stuff that it is only recently that I have been able to get any version to mostly work on my web paint-by-number site, though different versions failed for entirely different reasons.

Konqueror

This browser is a lot better than one would reasonably expect from something with so little visibility. Safari was derived from it, but the relationship doesn't always show. In mouse and key event handling, they are very different. It doesn't always seem like the fixes Apple made got back to the Konqueror people.

Netscape 4

Obviously nobody uses this anymore. It is sometimes included in these reports because it was the source of many defacto standards that newer browser more or less emulate, so it gives a little historical context to all this that can help make more sense of it all.

Mosaic

Ah, the simple pioneer days. I remember them well. No Javascript. No style sheets. No frames. No tables. I should go back to Mosaic, and stop worrying. This page renders great in Mosaic.