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!

On-demand JavaScript :: IE6/7 and Firefox 2.x

Last year, there was a lot of talk about on-demand JavaScripting. A good bit is found on Michael Mahemoff's Ajax Patterns Wiki. If you've never heard of it, you can read Michael's primer here.

Basically, on-demand JavaScripting helps you lazy load objects. When you need it, load it. It's simple.



You can run it here.

When you click on the "Load JavaScript" button, we're dynamically loading a JavaScript library by creating a script tag and then setting the src.

Then, the library loads and all the JavaScript is implicitly evaluated ( no eval is called ). You'll see an alert message appear saying that you've successfully loaded the JavaScript.

Close it and then the "Call method from new load" button is enabled. Click it and you'll see another alert message showing you the current page's HTML.

The whole exercise is to demonstrate that --

• You can load JavaScript dynamically by creating a script tag and then setting src
• You don't need to "eval" it

In fact, you can use the technique to "hack around" cross-domain issues and avoid using a proxy altogether. You can load JavaScript from any domain.

Though we can have lively debates on whether that's a good or bad thing, we're more interested in how the JavaScript was loaded.

From all the on-demand JavaScript examples that I've seen, they involve loading an external library, but what if we don't have an external library?

What if we just want to modify the body of the script tag to include new JavaScript? We might be loading the JavaScript from an iframe or some other external source and then slap it between script tags.

As it turns out, we can load JavaScript this way too, but we'll have to do it a specific way or it won't work in IE6 or IE7 ( I didn't try it for earlier versions of IE ) and like using "src", you don't need to explicitly evaluate the JavaScript.

Naturally, you might think that this works ( especially, since there's a general agreement that using innerHTML is the best and fastest way to dynamically update HTML ) --



Here's the example.

Try it in Firefox 2.x and it'll work. Then, try it in IE. We'll get the fabulously terse error message, "Unknown runtime error."

So, we try something along the same lines, but slightly different. Instead of updating with innerHTML, we'll create a text node using the string of JavaScript and then append that node as a child of the script element.



Here's the example.

IE chokes again, but this time with a bit more detail, "Unexpected call to method or property access". Sigh. It's beginning to look like one of those "many hours to solve" IE problems.

Fortunately, after a few more efforts, there's a solution. We'll use the "text" property found in the script node. Apparently, this is a Microsoft extension to the W3C DOM which works in Firefox 2.x. The best reference that I could find was here.



Here's the example that works in IE6/7 and Firefox 2.x.

We're done!

By the way, it's stuff like this that make using a JavaScript toolkit like Bindows worthwhile.

Have fun!