I was writing a script that dealt with images and I needed to know when an image had finished loading. Simple enough. Using Gimme (or your favorite addEvent(..)) equalizer the code looks something like:

It turns out that my load handler wasn't always firing in IE (in Firefox it worked consistently). The solution though is super simple.

You just need to make sure that you wire up the load handler before setting the image element's .src property. Why? Because if the image is being loaded from cache, IE (and Opera too) will load the image instantly. In fact, it will have finished loading the image before your load event handler is even wired up, which means, it won't fire!

Just change the code to something like this:

And there you have it.

Nothing earth-shattering and probably common knowledge for a lot of scripters, but a little refresher never hurts.

Under normal circumstances, IE won't allow you style tags that it doesn't recognize. But there is an interesting quirk in IE that will allow you to work around this and style unknown elements. All you have to do is create an element whose tag name is that which you desire to style, like so:

With the Javascript in place, you could then do:

Now IE will happily style all <myNewTag> elements with a red border, a blue background and bold text.

This goes for any tag that IE would not normally recognize, but it may prove especially useful in handling HTML5 down the road.

So there ya go... another IE quirk "to the rescue."

Auto Detach with 'unload'

In IE, if you wire up an event listener and fail to remove that listener when your page unloads, you're probably asking for a leak. One effective technique to ensure that listeners get removed is to wire up an 'unload' event to the window which detaches the listener for you. For example:

Keen readers might have noticed that I solved one problem (removing the 'click' listener from elem) by creating another one (attaching a new, anonymous listener to the windows's 'unload' event).

Why is this a problem?

In a previous blog entry, I mentioned that it wasn't possible to remove an event listener if that listener were anonymous, as in:

While it's true that the above code won't work, it's not entirely true to say that it's impossible to remove an anonymous listener. Why? Because every function actually has a reference to itself through its own arguments object. Specifically, through the .callee property of the arguments object.

We can use this to our advantage to detach the anonymous 'unload' listener from within the listener itself.

Why not just un-anonymize?

You certainly could just name all of your functions and then refer to them by name, but sometimes anonymous functions are very useful since they allow to create closures and do other nifty Javascript tricks. In those cases where it's desirable to use an anonymous function, this technique might be just the ticket!

Conclusion

I've conveniently (for me anyway) left out any non IE-specific code in this post. It's worth nothing that I don't generally use this technique except in IE, which means a little cross browser code is in order to ensure that this 'onunload' technique is only used for that browser.

Of course, it isn't going to hurt anything for other browsers (and it might even help) so there'd be no harm is using it across the board, bu you'll still need to write some cross-browser code (obviously). I'll leave that as an exercise for the reader though.

Happy scripting.

Comments welcome.

Gimme is a Javascript Library designed to make performing common tasks, not only easier, but down-right trivial.

What does Gimme look like?

Gimme is remarkably easy to use and was purposely designed to be very readable. Take the following snippet.

This code snippet grabs all elements on the page that have the class "moveable", adds to them, the class "hasBeenMoved," and then slides the elements (in a nice accelerated fashion) to the point (0, 0) on the page. Pretty easy right?

Believe it not, most tasks in Gimme are this easy (or easier).

Get started with Gimme

• See it in action on the Gimme Demo Page
• Learn what it can do at the Gimme API Reference Page.
• Download the source on the Gimme Releases Page.

Your Feedback

Gimme is still very young, but I'd love to get your feedback. Please don't hesitate to try it out and let me know what you think.

Recently, Kristoffer did a significant amount of investigation to track down a nasty IE memory leak issue. IE's problems with memory leaks are well known, but most of the time, you'll hear people saying things like "closures are the cause of memory leaks," or "failing to detach events is what causes memory leaks," and (probably the most common), "circular references are the culprit -- they cause memory leaks."

To some degree, all of these things are true. Closures can sometimes lead to memory leaks, failing to detach events can also lead to memory leaks, and yes, circular references to DOM elements can also be the cause of memory leaks.

One kind of leak that seems to get a little less attention though, is the one involving .innerHTML. Fortunately (thanks to Kristoffer's investigation) this one is pretty easy to deal with.

Before we can deal with the leak, we need to understand what causes it. Three conditions are required:

1. A orphaned DOM element must exist in memory.
2. That element's innerHTML must be set to a string of markup the creates an element with some DOM 0 event wired up.
3. The aforementioned innerHTML property must be set before the orphaned DOM element is "unorphaned" (added to the page).

If these conditions are met, get ready to call the (Javascript) plumber, because you've got a leak!

To make things a little less abstract, I'll write some code and explain piece by piece, how it fits the conditions above:

As you can see, the code above is not at all an uncommon scenario. Chances are though, if that's all you've got, you won't notice much of leak. This issue really only manifests itself when multiplied, that is, when you set .innerHTML in the above manner over and over and over again on the same page.

Why would ever do this? Think Web 2.0, think AJAX, think dynamic page updates and you probably won't have to search too hard to find a situation where someone might do this. Maybe you already know of (or helped write) a Web 2.0 app that does this.

Memory Leak Demo Page

Anyway, when above pattern is multiplied (whatever the reason) memory leaking chaos will ensue. To illustrate the problem, I've put together a sample page with a script that creates a orphaned <div> element, whose .innerHTML is set to a string of 2000 <a> tags with onclick events. When you click the "Start Leak" button, the script executes repeatedly, until you click the "Stop Leak" button. This give you a chance to use Perfmon to monitor memory consumption and see the results of the leak. The memory leak demo page can be found here.

The solution

It turns out, the solution is actually pretty easy: simply make sure to set .innerHTML after appending the DOM element to the page. That's it!

To see that this really does take care of the issue, I've put together another test page. In this one, the .innerHTML property is only set after the DOM element has been added to the page.

If you click the "Start Leak" button on each page and let it run for about 60 seconds or so, you should notice that the first page continues to consume more and more memory as time goes on, whereas the second page's memory consumptions remains relatively constant.

Demo Links

In case you're the kind of person who doesn't like to read paragraphs to find embedded links (I'm like that), here are the links to the two demo pages, for your convenicne:

• Leak Demo
• No Leak Demo

So there ya go: a nasty bug, but thanks to Kristoffer's work tracking tracking down the exact causes of this leak, a fairly easy one to handle.

Comments welcome.

Recently, in a personal project I'm working on, I came across a need to be able to represent any Javascript object as a string. This isn't a problem since just about every object in Javascript can be represented with JSON (Javascript Object Notation). Every modern browser can parse JSON for you easily enough through eval(..), and Gecko-based browsers even have the ability to reverse the process ("uneval" if you will) and give you back a string representation of an object through a call to .toSource().

If you need this ability in any other browser though, you're gonna have to write it yourself. I needed this ability, so I wrote it (and posted it here for your enjoyment!)

Gecko-based browsers, .toSource():

Gecko-based browsers provide a handy function: .toSource() that you can call on any object in your Javascript code to get back a JSON-like representation of that object.

Pretty simple right? You have an object; you want a string. Just invoke the object's .toSource() function.

Serializing objects in other browsers:

Serializing an object manually (as is required by non Gecko-based browsers) requires a bit of recursion. Simple types like integers, booleans, and even functions are trivial to represent as strings. Objects though, are more complicated because they can contain simple types or custom objects (which would need to be serialized themselves). Those "inner" objects could in turn, contain more custom objects, which would also need to be serialized, and this pattern could (theoretically) go on forever.

In practice of course, this pattern will (had better) come to an end. And we can leverage that fact to write a recursive function that will return a string representation (in JSON format) of a given object.

The serialize(..) function:

First the code, then the explanation.

Explaining a recursive function can be difficult, but I'll give it shot:

The function accepts just one parameter: the object (_obj) to be serialized. If you'll remember, I mentioned previously that simple types (string, boolean, number, etc...) were trivial because they all have an obvious string representation already. Complex types though, are more difficult because they can be made up of additional complex types, which in turn could be made up of additional complex types (and so on).

Of course, this pattern will eventually end; ultimately, everything is made up of simple types that have a string representation. The trick is figuring out how to traverse through this maze of "types within types." Recursion (simply stated: a function that calls itself) is perhaps the easiest way to solve this "types within types" problem.

Recursive functions always have a termination case -- something which causes the function to stop calling itself. Otherwise, the function would go into an infinite loop. In our function, there are actually four different cases in which the serialize(..) doesn't need to call itself:

1. typeof _obj is a number
2. typeof _obj is a boolean
3. typeof _obj is a function
4. typeof _obj is a string

If any of the above four conditions are met, returning a string representation is trivial, so we simply do it.

The only other case to deal with is when _obj is of type object. Within this case though, there are two "sub-cases" we need to deal with. The first is when _obj is an Array, or when it has a .callee property (more on that later). The second is well... anything else.

Basic Object Types

Your every-day, run-of-the-mill, object in Javascript can be represented as JSON with:

{ key1: val1, key2: val2, ... }

Where the keys are strings and the vals can be any simple type, or some custom object you've dreamed up. The logic I've used is to simply loop through a given object's keys and build a string of comma delimited, serialized key/value pairs that are wrapped in { and }.

Notice I said serialized key/value pairs. Here, our function is calling itself as it builds the object representation. This ensures that any objects within the object being serialized will also be serialized. If we didn't do this, we'd end up with a lot of strings that looked (something) like this:

{ key1: [object Object], key2: [object Object], etc... }

And that's clearly not what we want. We want those inner objects to be serialized as well, and that's what the recursive nature of our function will take care of for us.

Arrays

When _obj happens to be, not just any object, but more specifically, an Array, we have a better way of representing that as a string:

[ val1, val2, val3, ... ]

The logic I used here is to simply iterate through the array building a comma delimited list of serialized values, wrapped in [ and ]. Arrays in Javascript already have a .toString() function, but we can't use it here; if the Array contains objects, then the result of the Array 's .toString() could end up something like:

[ [object Object], [object Object], etc... ]

Again, not what we want, so we need to make sure we recursively serialize all of the elements in the array.

Arguments (the .callee "gotcha")

There's one bit of code I haven't discussed yet and it deals with the (possible) .callee property of the passed in _obj. It turns out that .toSource() (native function used by Gecko-based browsers) doesn't do anything very useful when called on an arguments object.

The arguments object is an array-like (but not an Array) object that is automatically available within the scope of every function. Unfortunately, no matter what is contained within that arguments object, calling .toSource() on it will always return "({})"

In order to be able to serialize an arguments object then, we need some way to detect it and then treat it like an array. The .callee property is a good choice because arguments objects have it, but other objects (to the best of my knowledge) do not.

In the case of the serialize(..) function, I decided to use the native .toSource() function whenever it was available, unless the object were an arguments object, in which case, I send Gecko-based browsers down the same path as all other browsers for serialization.

Finally, just for good measure, I've added a default case which returns the string UNKNOWN to handle a situation where no other cases applied. Of course, we probably don't want UNKNOWN showing up in the our serialized strings, but it probably won't do much (immediate) harm if it ever does show up, and its presence would be a helpful indicator that there is some case not being met (that probably needs to be).

Conclusion:

What would you ever use a function like this for? Well, In my case, I wanted to use a Javascript object as the key for a hash, but if I tried to do that, Javascript would just represent all of my (different) objects as the same string: [object Object], which wouldn't do me any good. By serializing the object, I can then use that serialized representation as a key in the hash.

It's worked well for my need so far, but I haven't tested it a great deal. If you find any bugs or short-comings, please let me know.

As always, comments are welcome.