#12172 is a duplicate of this ticket.

The test case boils down to this:

    $('<div/>').bind('click', function(){});
    $('tt').bind('click', function(){});

You said the div that was leaked was one of jQuery's support test elements, are you sure it's not the div from the test case? Does a test case with just one of the lines above leak as well? I can't try it myself at the moment.

Replying to [comment:2 dmethvin]:

You said the div that was leaked was one of jQuery's support test elements, are you sure it's not the div from the test case? Does a test case with just one of the lines above leak as well? I can't try it myself at the moment.

Retested the disconnected div changed to a code tag.

   $('<code/>').bind('click', function(){});
   $('tt').bind('click', function(){});

The following elements leak:

• the bound tt element
• the disconnected code element
• the html element
• a div element (a generated support element?)

Testing this with jquery1.7.2 leaks only the tt and code elements.

If I remove the line for the tt bind then I get 3 leaking elements (the tt is no longer leaked). If I remove the line for the code bind then there is no leak as would be expected.

Hope that clarifies things.

Okay, this needs more investigation.

#12949 is a duplicate of this ticket.

Good morning, is there any known workaround or patch for this problem?

I too have it, on ever page reload using latest jQuery and jQuery UI around 5-15 mb is leaked on IE7

I created a wokraround in jQuery UI 1.8.19 by cleaning up the dpDiv variable in the Datepicker when the window is unloaded. Unbind it and set to null. Have not tested it on later versions.

This change removed the memory leak that occured by just including jQuery and jQuery UI on any page.

Bear in mind the original case was unrelated to JqueryUI. Still unresolved.

Still unresolved.

Yes, thats what the **(open bug)** means at the top of the page. If you have the time please take a look, we'd welcome the help. But please don't bump the ticket.

Replying to [comment:9 peter.nystrom]:

I created a wokraround in jQuery UI 1.8.19 by cleaning up the dpDiv variable in the Datepicker when the window is unloaded. Unbind it and set to null.

Can you please provide the code for this?!

I was able to fix this in IE6 by adding window unload event handling for undelegating the bound events that were creating circular reference. This change was added directly to the end of the function Datepicker(){...}.

Clearing of the object references is just fluff, the real meat of the memory leak problem can be turned on and off by simply commenting in and out the line that does the undelegate.

function Datepicker() {
        ...

        var self = this;
        $(window).unload(function(){
            var selector = 'button, .ui-datepicker-prev, .ui-datepicker-next, .ui-datepicker-calendar td a';
            //this line if the magic
            self.dpDiv.undelegate(selector, 'mouseover mouseout');
            self._dialogInst = self.dpDiv = null;
        });
}

Sorry for pasting the entire jquery ui lib in the js window, but here is the fix in action:

http://jsfiddle.net/ctoestreich/JFETB/

As a bit of clarification, the method to add the module datepicker to jQuery is fired on page load and even when not specifically using datepickers on your page, simply the act of including the library would cause the problem as the orphaned object delegates were getting created on page load by:

 $.datepicker = new Datepicker(); // singleton instance

This is called by the module on every load which in turn calls the object construction and adds the dpDiv and its event delegates that get orphaned due to circular references and being unattached to the dom in any way.

Cheers!

My solution was similar to the one above, I created this function in the Datepicker that was called on window unload:

	cleanup: function(target) {
		this.dpDiv.unbind();
		this.dpDiv = null;
	},

We don't have the resources or inclination to fix this, and it's not a fatal error. Given the point we're at with IE6/7 support we're unlikely to land a fix unless it was only one or two lines, but if someone has such a fix we could consider it.