Javascript Madness: Introduction

Jan Wolter
May 6, 2008


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.

All the programs and code fragments that I have written for these pages can be treated as being in the public domain, free of copyright, OK to use in any way without any legal restrictions. You are encouraged to apply the information and techniques described here anywhere you find them useful without restriction. The text of the articles themselves are all copyrighted by Jan Wolter, however.

You can also take it as given that I offer all the code and information on these pages without warranty or guarantee of it's correctness or suitability for use. So don't sue me.


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.

Parsing Query Strings
How to read arguments from the URL in Javascript, with a long digression into the many problems with Javascript's built-in URI encoding and decoding functions.

Ill-Informed Grousing About Browsers

For years I have used this section to vent my annoyance at all these crummy browsers. While other people touted their favorite browsers, I'd grown to dislike them all for various reasons and in various degrees.

But things have changed. Browsers have actually gotten pretty good at supporting the basic needs of Javascript programmers. It's kind of astonishing.

Internet Explorer
For a very long time, Internet Explorer has been the leading source of headaches for web developers. IE started out buggy and incompatible, and then development pretty much stopped between 2000 and 2006. While other browsers got better, the one most people used just kept stinking. Virtually all web developers got to hate it, because everything had to be carefully programmed to work around all it's bugs. But then a miracle happened. As far as I can tell, Internet Explorer 9 is a fully capable modern browser, that supports the core standards as competently as any of it's competitors. It's actually OK. It really is. IE OK? IE OK. IE OK! My brain can't quite grasp it, but it seems to be true.

Long ago the Netscape browser introduced many of the key innovations that made browsers cool, but Netscape went bust and the Mozilla foundation picked up the pieces to rebuild that musty old code into the leading open source browser. The Mozilla developers generally proceed at a rather plodding pace. They are hardly ever the first, but they keep up. Minor bugs often seem to take years to get fixed, but new releases rarely introduce new bugs. 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. 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. Once Firefox was just one of many browsers using Mozilla's Gecko rendering engine, but while others still exist, the have increasingly fallen by the wayside. New browsers these days are more likely to be based on Webkit than Gecko.

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. Then it seemed like their competitive exuberance began 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.

Chrome uses the same open source rendering engine as Safari, so for my purposes it is mostly the same. It's most notable for a very fast release cycle.

This is the browser that has caused me the most headaches over the years. When 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 was always speedy and nimble. Every release was 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 generally they were not actually fixed for a long time. I sometimes wished they would slow down and figure out how things are supposed to work instead of patching patches. Tracking what did and did not work in Opera was a constant headache. But, as with IE, recent versions have pretty much settled down to a fairly good approximation of correctness.

This browser is a lot better than one would reasonably expect from something with so little visibility. Safari and Chrome were 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 makes get 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.

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.