Skip to main content

Search and Top Navigation

#8164 closed bug (patcheswelcome)

Opened March 06, 2012 01:59PM UTC

Closed April 19, 2016 01:15PM UTC

Memory Leak using IE8/9 with datepicker and frameset

Reported by: gianlucamaggio Owned by:
Priority: minor Milestone: none
Component: ui.datepicker Version: 1.8.18
Keywords: Cc:
Blocked by: Blocking:

I have a memory leak (memory not released after page exit) using jQuery UI in a page inside a FRAME of a FRAMESET by simply including jquery-ui-1.8.18.custom.min.js. I cannot post to jsFiddle because I need two pages to reproduce it.

The page reload itself each 100ms to show how quickly the memory increase.

I have the problem only with jQuery 1.8. No problem with jQuery 1.7.

This is the code of Home.html:

<!doctype html />
<frameset cols="100,*" target="cfmain" frameborder=yes framespacing=0 hidefocus >
	<frame name="cfmonitor" id="cfmonitor" src="about:blank" scrolling="yes" noresize>
	<frame name="cfmain"  id="cfmain" src="testjq.html" >


And this is the code of the contained page (testjq.html):

<!DOCTYPE html />
<script src="JQuery/jquery-1.7.1.min.js" type="text/javascript"></script>
<script src="JQuery/jquery-ui-1.8.18.custom.min.js" type="text/javascript"></script>

<LINK REL="stylesheet" HREF="JQuery/themes/cupertino/jquery-ui-1.8.18.custom.css">

<title>JQuery Test Page </title>
<script language="javascript">

    $(function () {
        window.setTimeout("window.location.href = 'Testjq.html'", 100);



<body >
    <h1>simple test</h1>

This is the memory running with IE8 on Windows 2008 (the same also in IE9 Win7)


Attachments (0)
Change History (10)

Changed March 22, 2012 07:26PM UTC by wings13 comment:1

I am seeing the exact same problem.

I have tracked this down to the jquery.ui.datepicker changes introduced in 1.8.13. This example will not leak in 1.8.12 but it will leak in 1.8.13. If you take the 1.8.12 source and add the 1.8.13 datepicker changes it begins to leak. I'm not confident enough in these changes to understand what exactly is causing the leak yet - other than IE and framesets ;)

Changed May 08, 2012 09:51PM UTC by scottgonzalez comment:2

component: ui.coreui.datepicker
summary: Memory Leak using IE8/9 with jquery UI and FRAMESETMemory Leak using IE8/9 with datepicker and frameset

Changed July 06, 2012 02:23PM UTC by Alex comment:3


we had also the same problem. Function bindHover(dpDiv) seems to be the problem.

Our solution is to return dbDiv without register the mouse events.

For us it's enought.

Bye Alex

Changed September 12, 2012 07:21PM UTC by sorpigal comment:4

Following up on Allex's comment, if you still need hovering you can change the delegate to using .live() like this:

	var selector = 'button, .ui-datepicker-prev, .ui-datepicker-next, .ui-datepicker-calendar td a';

	$(selector).live('mouseout', function(){
		if (this.className.indexOf('ui-datepicker-prev') != -1){
		if (this.className.indexOf('ui-datepicker-next') != -1){
	}).live('mouseover', function(){
		if (!$.datepicker._isDisabledDatepicker( instActive.inline ? dpDiv.parent()[0] : instActive.input[0])) {
			if (this.className.indexOf('ui-datepicker-prev') != -1){
			if (this.className.indexOf('ui-datepicker-next') != -1){

	return dpDiv;

This stops on-load leaking in at least IE8 but leaves hovering apparently functioning at the cost of some (significant) CPU overhead.

Changed October 11, 2012 02:45PM UTC by scottgonzalez comment:5


Changed October 19, 2012 08:18PM UTC by mikesherov comment:6

status: newopen

Changed January 29, 2013 05:06PM UTC by maverick9984 comment:7

Hi there,

Is there a plan on fixing this memory leak in IE 8/9 ?


Changed January 29, 2013 05:25PM UTC by scottgonzalez comment:8

Sure, send a pull request. Otherwise, it probably won't happen until the rewrite lands in master.

Changed June 24, 2014 11:52PM UTC by scottgonzalez comment:9

milestone: 1.11.0none

Changed April 19, 2016 01:15PM UTC by scottgonzalez comment:10

resolution: → patcheswelcome
status: openclosed

I'm going to close this since we're very far along in the rewrite. Since none of the existing code exists in the rewrite, this particular bug won't persist.