Question

Here’s a sample page with a couple datepickers. Here’s the Drip result for that:

alt text http://www.picvault.info/images/537090308_omoya.png

This page leaks indefinitely in IE6sp1 when I click the Refresh button repeatedly (IE6sp3+, Opera 9, Chrome2, and FF3+ seem to be good). The memory goes up and never goes down until I actually close the browser completely.

I’ve also tried using the latest nightly of jquery (r6414) and the latest stable UI (1.7.2) but it didn’t make any difference. I’ve tried various things with no success (CollectGarbage, AntiLeak, others).

I’m looking for a solution other than “use a different browser!!1” as I don’t have any control over that. Any help will be greatly appreciated!

Update 1: I added that button event to a loop and this is what happens (the sudden drop off is when I terminate IE):

Update 2: I filed a bug report (fingers crossed).

Update 3: This is also on the mailing list.

Update 4: This (as reported on the mailing list) doesn’t work, and in fact makes things worse:

$(window).bind("unload", function() {
  $('.hasDatepicker').datepicker('destroy');
  $(window).unbind();
}); 

It’s not enough to just call destroy. I’m still stranded with this one and getting very close to ripping jquery out of the project. I love it (I really do!) but if it’s broken, I can’t use it.

Update 5: Starting the bounty, another 550 points to one helpful individual!

Update 6: Some more testing has shown that this leak exists in IE6 and IE6sp1, but has been fixed in IE6sp2+. Now, about the answers I have so far…

So far all answers have been any one of these:

1. Abandon IE6sp0/sp1 users or ignore
   them
2. Debug jquery and fix the problem myself
3. I can’t repro the problem.

I know beggars can’t be choosers, but those simply are not answers to my problem.

I cannot abandon my users. They make up 25% of the userbase. This is a custom app written for a customer, designed to work on IE6. It is not an option to abandon IE6sp0/sp1. It’s not an option to tell my customers to just deal with it. It leaks so fast that after five minutes, some of the weaker machines are unusable.

Further, while I’d love to become a JS ninja so I can hunt down obscure memory leaks in jquery code (granted this is MS’s fault, not jquery’s), I don’t see that happening either.

Finally, multiple people have reproduced the problem here and on the mailing list. If you can’t repro it, you might have IE6SP2+, or you might not be refreshing enough.

Obviously this issue is very important to me (hence the 6 revisions, bounty, etc.) so I’m open to new ideas, but please keep in mind that none of those three suggestions will work for me.

Thanks to all for your consideration and insights. Please keep them coming!

Update 7: The bounty has ended and Keith’s answer was auto-accepted by SO. I’m sorry that only half the points were awarded (since I didn’t select the answer myself), but I’m still really stuck so I think half is fair.

I am hopeful that the jquery/jquery-ui team can fix this problem but I’m afraid that I’ll have to write this off as “impossible (for now)” and stop using some or all of jquery. Thanks to everyone for your help and consideration. If someone comes along with a real solution to my problem, please post and I’ll figure out some way to reward you.

Answer 1

I hate to say this, your approach is correct and professional, but I’d be tempted to just leave it.

The consequences of not fixing this is that IE6 users will notice their machine getting slower and slower and ultimately either crashing completely or more likely crashing IE6.

So what?

Really – why is this your problem?

Yours definitely won’t be the only site they visit with this leak, and they will see IE6 crash regularly regardless of what you do, because that’s what it does.

It’s unlikely that anyone still on IE6 could even point out your application as one that leaks.

Finally when IE6 does crash it reports IE6 as the culprit – you can legitimately point out that this is a bug in IE6 that Microsoft have fixed in a new release.

Your expensive time is better spent on improving the application for the users not trapped in legacy hell – your app should basically work for IE6 users, but this sort of issue can suck away all of your time and not fix their problem. IE6 is still going to be an unsupported, crash ridden, security hole of a browser.

I suspect the jQuery devs take a similar view to me. Also you have to do some really ugly stuff to get round this bug in IE6, including hacky DOM work that stops the leak but is actually much slower.

---

Update

Ok, this isn’t an easy problem to fix – MS describe the IE6 bug (and provide advice on how to fix it) here: http://msdn.microsoft.com/en-us/library/bb250448(VS.85).aspx

Basically this isn’t a problem with javascript or jQuery – the actual issue is with the IE6 DOM – when HTML elements are added to the page (by javascript, rather than being in the page when it loads) IE can’t garbage collect them unless they are created in a very specific way.

This is back to front from how jQuery UI builds elements (see DOM insertion order bug in the link above) and so this isn’t something that either the jQuery devs or you can easily fix.

So how do you fix the issue? Well, you can stick with the legacy pop-up calendar for IE6 or you can write your own one.

I would recommend the former, but if you really want to built the latter there are some basic rules to follow:

1. Always add elements top-down – for instance if you want to built a table add the <table> element into the page’s DOM, then add <tr> then <td> and so on. This is back to front as it’s much quicker to build the entire table and then add it to the DOM – unfortunately that’s where IE6 loses track of it.

2. Only use CSS and HTML 3.2 attributes – sounds dumb, but IE6 creates extra objects to store the extra attributes (or ‘expando’ properties) and these also leak.

3. Kinda related to (2), but as @gradbot mentions IE6 has problems garbage collecting javascript variables – if they reference a DOM element inside an event fired from that element you can get problems. This is also compounded by javascript references to DOM elements that have ‘expando’ properties.

If you have a look around online there may already be a drop-down DHTML calendar that sticks to these rules – it won’t be as pretty, quick or configurable as the jQuery UI one, but I’m sure I’ve seen it done without leaking in IE6.

I think the best bet is to keep as much static as possible – for instance you could load the calendar grid (week numbers and day column headings) with the page and then dynamically load in the numbers (and nothing else). Create the day numbers as links, with javascript in the href – not best practice normally but far less likely to leak in IE6.