Thursday, September 20th, 2007
IE6 Leak on Form Tag
Jon Sykes happened across another IE 6 leak to do with form tag orphans. The bug means that (as of yet) there seems to be no way of removing a FORM tag from the DOM without it resulting in an orphaned node and increased memory consumption.
It seems to have minimal documentation, and I can’t see any obvious solution.
If you have a “web application†that uses any form of partial page loading, and the content you are loading contains any form elements, in IE6 memory usage will climb as you use the app, leading to initially a sluggish browser and finally total terminal failure.
As many of the toolkits these days come with this style of content loading mechanism (take for example my toolkit of choice dojo, with it’s contentPanes), it’s very easy to get into a situation where your webapp will be unacceptable to folks using IE.
It’s been a tough week for memory leaks.





Damnit! I have tons of this going on.
For these types of applications, I generally have one FORM tag encapsulating the entire page. I then have my update functions change the action on the form, thus not having to add (and supposedly not remove), form tags at all.
@James. You are obviously unable to nest forms, so to get around this you use one giant form and change the action and send all of the data onSubmit?
Fix: set the elements collection to null.
form.elements = null;
@ James, yup there are a number of ways to ‘mitigate’ the impact, my bigger concern was in situations where those options aren’t possible and a true fix/hack/workaround is needed. A good example is a situation we often get at work, where many of the pages already exist in a traditional web architecture, and we then need to convert them into a more rich ‘web2.0’ style setup, with a minimal change to the page code. It also occurs if you’re working in a progressive enhancement situation where the code needs to work in both worlds. Final issue, is pages that have lots of forms, having one just isn’t practical if the original page has 10+ forms in it.
@Sjoerd : could you explain more what you mean? The code you posted just throws exceptions in IE6.
Oops, sorry guys
After restarting my IE6 i also was getting the errors, maybe because of the earlier pollution i wasnt get any errors and the script wasnt continuing in it’s loop (and so creating only 1 form tag).
Will look further ;-)
Now i found it (and without errors), after the removeChild() call the removeNode()
document.body.removeChild(a);
a.removeNode();
Tried:
removeNode() after traditional garbage collection, no cigar.
for( var x = 0; x
and removeChild then removeNode as you mentioned above, no cigar.
for( var x = 0; x
^ sorry about that, note to self, posting code will not work.
This works for me:
for( var x = 0; x <= 5000; x++ ) {
var a = document.createElement(‘form’);
var b = document.body.appendChild(a);
document.body.removeChild(b);
b.removeNode();
}
Commenting out the removeNode introduces memory increase (leaks in Drip)
Weird I still get the 10000 orphaned nodes
with this test in sIEve
MS needs to use that auto-update without user notification feature again to updated everyone to IE7. Or better yet some needs to hack that auto update without notification feature to replace everyones copies of IE with Firefox.
General quirk.. a blank page with a form node reports as having 2 references to the form node for “in use” under sIEve.
Why? Is this part of the problem?
Twist… Please tell us your joking. I was one of those on the phone to MS the day they gorilla pushed IE7 on our enterprise. We had less impact from the MyDoom worm.
@ TI: Yup I see that too, what’s awesome is running…
<script type="text/javascript" charset="utf-8">
for( var x = 0; x <= 10000; x++ ) {
document.getElementById('holder').innerHTML = "<form></form>";
document.getElementById('holder').innerHTML = "";
}
</script>
Seems to still leave you with 10009 nodes “in use”. I’m at a lose.
Update using the solutions detailed above.
I have examples of it in action against the test cases, and a quick and dirty example of it used as part of Dojo’s ContentPane widget.