> One especially crazy seeming one from today's perspective is that there's a separate implementation of event propagation, I believe because because it dates back to browsers that only implemented one half of event bubbling/capture!
MSIE only supported bubbling, Netscape 4 only supported capturing. The DOM Level 2 model (which combined both) started getting supported around IE5 / NS6 / Mozilla, though support would remain spotty for a while especially on the IE side.
Microsoft's event model also worked off of a global (`window.event`) for the event information rather than a callback parameter which was fun.
And there was no "current target" passed to the callback (or available on `window.event`), which meant you had to keep a handle on the event target from your callback, which caused a cycle between the DOM and Javascript, which created a memory leak by default: IE's DOM was a COM API, while JScript was its own separate non-com runtime. By creating a cycle between the two, the JS handle would keep a COM refcount > 1 on the page's DOM, and the event target would (through the event handler) keep a foreign JScript handle, and then neither could be collected.
And because IE's COM instance was per-process the leak would live until you closed IE itself, every reload of the page would create a new document in COM, an event handler in JScript, and leak the entire thing. You had to explicitly break the cycle by hand by detaching your events during e.g. onunload.
In fact there was a tool called "drip" whose sole purpose was to open a page in an HTML control, then loop reloading the page and counting COM objects. If the number increased, you had a leak (almost certainly due to an undetached handler), and now… you had to find where it was.
edit: and the state of tooling at the time was… dismal is too kind a word. This was before Firebug and console APIs, so your tools were either popping `alert` for debugging (this was also before JSON support in browser so serializing objects for printing was neat) or installing a debugger, which were universally shit and only handled *javascript debugging:
Mozilla had Venkman, which was dog-slow and had a weirdly busy UI.
Microsoft had either the Script Debugger or Visual Studio's debugger. SD was extremely brittle and would crash if you looked at it funny while VS was heavyweight and expensive. SD was also completely unable to debug scripts at the toplevel (of JS files or <script> tags), it only worked inside functions. I don't think VS supported that either but I don't remember as clearly so it might have. The best part of that was that you could set breakpoints at the toplevel, they just wouldn't ever trigger.