Opened 8 years ago

Closed 3 years ago

#8164 closed bug (patcheswelcome)

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:

Description

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 />
<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" >
</frameset>

</html>

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

<!DOCTYPE html />
<html>
<head>
<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);
    });

</script>

</head>

<body >
    <h1>simple test</h1>
	<h2>Reloading...</h2>
</body>
</html>

This is the memory running with IE8 on Windows 2008 (the same also in IE9 Win7) http://s10.postimage.org/5ketngvyx/Memory_Leak.jpg

Change History (10)

comment:1 Changed 8 years ago by wings13

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 ;)

comment:2 Changed 7 years ago by Scott González

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

comment:3 Changed 7 years ago by Alex

Hi, 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

comment:4 Changed 7 years ago by sorpigal

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(){
		$(this).removeClass('ui-state-hover');
		if (this.className.indexOf('ui-datepicker-prev') != -1){
			$(this).removeClass('ui-datepicker-prev-hover');
		}
		if (this.className.indexOf('ui-datepicker-next') != -1){
			$(this).removeClass('ui-datepicker-next-hover');
		}
	}).live('mouseover', function(){
		if (!$.datepicker._isDisabledDatepicker( instActive.inline ? dpDiv.parent()[0] : instActive.input[0])) {
			$(this).parents('.ui-datepicker-calendar').find('a').removeClass('ui-state-hover');
			$(this).addClass('ui-state-hover');
			if (this.className.indexOf('ui-datepicker-prev') != -1){
				$(this).addClass('ui-datepicker-prev-hover');
			}
			if (this.className.indexOf('ui-datepicker-next') != -1){
				$(this).addClass('ui-datepicker-next-hover');
			}
		}
	});

	return dpDiv;

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

comment:5 Changed 7 years ago by Scott González

Milestone: 1.9.01.11.0

comment:6 Changed 7 years ago by mikesherov

Status: newopen

comment:7 Changed 7 years ago by maverick9984

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

Thanks

comment:8 Changed 7 years ago by Scott González

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

comment:9 Changed 5 years ago by Scott González

Milestone: 1.11.0none

comment:10 Changed 3 years ago by Scott González

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.

Note: See TracTickets for help on using tickets.