Last week I pushed a new application up to production, and started hearing complaints of a memory leak. After running some diagnostics I learned two exciting things:
http://bugs.jqueryui.com/ticket/7666
The current version of jQuery UI (1.18.16) has a memory leak with the DatePicker control - including the DatePicker control as part of the jQuery UI is all it takes to cause memory to be allocated and never returned until the browser is closed. Every refresh of the page, or every time a new page is loaded, more memory is allocated to the browser process.
Although my application did not utilize the DatePicker control, it came as part of the default jqueryui package and I did not go out of my way to exclude the DatePicker from the jqueryui package.
This reminded me of an important aspect of software design: The more features a system has, the more features a system has that can go wrong. Although today we may believe our system to be safe and secure, new vulnerabilities will undoubtably be found tomorrow proving that we weren't so safe after all. Exposing additional functionality that is not intended to be used is potentially dangerous and in my case caused an unecessary memory leak.
At the same time I discovered another memory leak in my implementation of http://datatables.net/ that applies to IE 7.
I had a table like such:
/* Using aoColumns */
$(document).ready(``function``() {
$(``'#example'``).dataTable( {
"aoColumns"``: [
{ "fnRender"``: function ( oObj ) {
return "<div onMouseOver=\"alert('abc');\">" + oObj.aData[0] + "</div>"``;
} }
]
} );
} );
(In other words, I added some basic javascript functionality at render time to the outputed html of my datatables.)
I noticed that when I would page forwards and backwards through my datatable, memory was being leaked within Internet Explorer - In the html of the table, we have a javascript onMouseOver event which was being registered against the DOM, but since the datatables library did not do the registering, it did not know to unregister the event before loading the next page of data.
Instead of registering the events to the cells themselves, I switched to event delegation (http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html) which is a much better strategy than registering an event listener for every row of a table that could potentially be several hundred rows long.
Two memory leaks down. How many more could there possibly be?...