IE Memory Leaks

Mark Wubben blogged that Microsoft recently released a security patch that among other things fixed memory leaks in IE 6.0 on XP. Specifically, Microsoft mentions a fix for --

"A memory leak occurs in Internet Explorer 6 when you view a Web page that uses JScript scripting on a Windows XP-based computer"

More details are found here.

It's important to note that the fix is only for IE 6.0 running in XP. It doesn't address IE 6.0 running in W2K or IE 5.5. It's also a patch that's applied to the entire OS with a number of other fixes. So, some people ( ex. corporations ) may be hesitant to install it until they've fully verified that the patch is more beneficial than hurtful.

Of course, if you're using IE 7, none of this matters because memory leaks don't occur there anymore.

With these elements in play, I'd thought we'd review memory management in IE.

Memory leaks occur in IE because of circular references between DOM elements and JavaScript objects ( it's really JScript objects -- Microsoft's implementation of JavaScript ).

Circular references aren't a problem with other browsers just IE. This is because IE uses two different memory managers -- one for DOM elements ( DOM elements are represented as COM objects and so use the COM garbage collector ) and one for JavaScript objects which uses a different one.

Since the two memory managers don't communicate with one another they don't know that there are "islands" of circular references which are no longer used. The memory managers get confused and then bad things happen.

Note that I've simplified this a lot. If you want the gory details read Joel Webber's dated but really good description of the issue.

In IE, when memory leaks happen, they don't go away when you navigate to a new page. Instead, the memory loss carries over. If you use a process/memory viewer like Process Explorer, you'll observe this.

The only way to free the memory ( other than breaking the circular references ) is to close and restart the browser.

Circular references between DOM and JavaScript objects are common. If you've ever attached an event to a DOM element and have your event handler refer back to the element, you've created a circular reference. They can also occur when you create closures ( inner functions can access variables outside of itself even after the enclosing function has returned ), but the more common occurrence is the first one.

Fortunately, it's easy to break the circular reference and as it turns out, it's easier to break the link from the DOM rather than from the JavaScript side of things.

For events, you do it differently depending on how you've attached the events.

DOM Level 0 Events
All browsers support Level 0 event handling. This is probably the first type of event handling that you learned when learning about HTML and JavaScript events. Level 0 event handling allows you to attach events directly to the HTML element like this --

<div id="SomeDiv" onclick="handleClick();"></div>

The div element has a reference to the JavaScript object handleClick via the onclick attribute. If the method handleClick has a reference back to the div ( for example "this" ), then a circular reference occurs.

It's not optimal to review every event handler to see if a circular reference exists. It's better to just unhook the event handler when you no longer need it.

So, follow this maxim of symmetry - if you add it, remove it.

For DOM Level 0 events, removing it is pretty easy. You nullify it --

<script type="text/javascript">
var someDiv = document.getElementById("SomeDiv");
someDiv.onclick = null; // Set the handler to null
</script>

DOM Level 2 Events
DOM Level 2 event handling supports a number of methods such as addEventListener and removeEventListener. The equivalent methods in IE are attachEvent and detachEvent respectively. We follow the same symmetry with Level 2 events. We add events like this ( with the IE methods ) --

obj.attachEvent( 'onclick', handleClick );

then, we do this to remove them --

obj.detachEvent('onclick', handleClick);

A generic way to do this is to use a Singleton object that abstracts how to add or remove events so you don't have to worry about the browser you're using --

It's best to cleanup the events when you "unload" from a page. Listen for the unload event and when that occurs, have your event handler remove the event handlers.

Here's a DOM Level 0 example and here's a DOM Level 2 example for you to try.

I hope that this is something you can use in your own code.

Have fun!

Bindows Wonderful dispose() Method

Almost anything useful you do with Bindows requires you to add components to other components. This is because you build visual components by creating parent child relationships.

So, if you wanted to build a custom dialog, MyDialog, you might start off with a BiComponent and use that as a container. Then add a BiToolBar to the BiComponent. Of course, you'll need toolbar buttons and menus so you add BiToolBarButtons and BiToolBarMenuButtons to the BiToolBar, etc.

When you're done, you add the BiComponent container to the BiApplicationWindow.

We've effectively created a hierarchy where every component with the exception of the BiApplicationWindow is a child to another.

One reason why this is significant is when you dispose MyDialog.

All derivatives of BiComponents have access to a dispose() method. It may come directly from the component ( for example BiLabel has its own dispose method ) or directly from BiComponent or from BiObject ( read about dispose() ). As a front-end developer, you don't really care. You just have to remember to call it when you want to mark MyDialog for garbage collection.

So, calling dispose() traverses the children, removes their properties and sets them to null ( actually BiComponent's dispose() calls another method, disposeFields() which makes this happen, but it's all nicely abstracted for you ).

In cases where you only have a hierarchical relationship between your components, you don't need to implement dispose(). This is cool because all you do is call dispose() and the world is your oyster. Most of the time this is all you need to do.

However, if you create new objects in a custom component like MyDialog ( perhaps, we have an array of strings in MyDialog that we're using to temporarily store information ), then we'll need to implement our own dispose().

If we do, we need to make sure that we --

• Call dispose() in the superclass ( for MyDialog, the superclass is BiComponent and can be done like this - BiComponent.prototype.dispose.call(this) ); this effectively propagates the disposal up the prototype chain

• Call disposeFields(); disposeFields accepts a variable number of string arguments where each string is a property name; calling disposeFields removes ( i.e. deletes ) the property and disposes them if it's a Bindows objects; you can read about it here.

That's it. dispose() is pretty wonderful.
Have fun!