Skip to main content

Bug Tracker

Side navigation

#186 closed bug (fixed)

Opened September 08, 2006 02:24AM UTC

Closed October 11, 2009 02:13PM UTC

Last modified March 15, 2012 12:49AM UTC

IE memory leak

Reported by: Owned by:
Priority: undecided Milestone:
Component: ajax Version:
Keywords: memory leak Cc: &#34
Blocked by: Blocking:

Use the full jquery library in a page, and the IE memory usage starts running up every time the page is refreshed. Even if you don't use any jquery functions at all.

Attachments (0)
Change History (12)

Changed September 15, 2006 05:26PM UTC by Steve O comment:1

I can confirm this, it seems to jump by anywhere from 100K to 300K every refresh.

Changed September 27, 2006 05:19PM UTC by anonymous comment:2

This is a BIG deal-breaker for me. I can not faithfully use this framework with such a large memory leak occuring so consistently.

Changed September 27, 2006 09:32PM UTC by joern comment:3

Maybe we should try to include MGs closure plugin into the jQuery core...

Changed October 18, 2006 01:15PM UTC by anonymous comment:4

please fix this ASAP. No library worth the name should be afflicted with the notorious IE memory leak. I agree with joern: use the closure plugin or something similar. The codebase isn't that big, someone should be able to do this in no-time!

Changed October 24, 2006 07:36PM UTC by Steve O comment:5

I did some testing to try to isolate this leak in the code. I am using Rev 413 and my steps to reproduce look like this: (1) create a basic HTML page linking to the jquery code as normal, and (2) refreshing the page consecutive times in IE6 and monitoring the memory usage in the process monitor in the Windows Task Manager. There is no jquery code in the file except including the library itself. Refreshing the page causes a memory increase of 100-300K for every refresh.

In order to stop the leak, I have to comment out BOTH of the following:

1221: jQuery.fn[o] = function(f){

1222: return f ? this.bind(o, f) : this.trigger(o);

1223: };

  • AND -

1291: jQuery.event.add( window, "load", jQuery.ready );

If I only comment one out and not the other, the leak still happens. If I remove both of them from the code, the leak stops.

I hope this helps someone figure this one out... I will continue to try, but my JS event knowledge is next to nothing. I imagine that this bug is stopping quite a few people from embracing JQuery in production code, like it is at my company. It will be great to see this one squashed.

Changed October 24, 2006 07:52PM UTC by anonymous comment:6

I did a little more digging and it turns out that I was able to stop the leak by commenting out JUST line 917: element["on" + type] = this.handle; (which is in jQuery.event.add).

Further tweaking led me to the jQuery.event.handle function and subsequently to the jQuery.event.fix function. If I comment out lines 991 - 997 in Rev 413 (the assignment of preventDefault and stopPropagation functions) then the leak stops.

So, maybe the leak is being caused because those two functions are being attached to the event object?

Changed October 24, 2006 08:33PM UTC by Steveo O comment:7

OK... more digging. My testing showed that if you loop through every event that has been added via jQuery.event.add and set the event's properties preventDefault and stopPropagation to null when the page unloads (I personally did this in the IE cleanup function starting on line 1296 in Rev 413), then there is no leak. I am not sure if this is safe to do or not--but it appears to stop the leak.

I don't really have a patch... I am not really sure how to create one, but I hope this information helps someone!


Changed October 25, 2006 04:55PM UTC by anonymous comment:8

component: → core
owner: anonymousjohn
priority: → major
type: → bug

Changed November 01, 2006 04:23PM UTC by brandon comment:9

owner: johnanonymous
status: newassigned

Thanks Steveo O for all the testing ... I'm going to try this out myself and get a patch together.

Changed November 02, 2006 02:48PM UTC by brandon comment:10

resolution: → fixed
status: assignedclosed

Steveo O, you testing has been invaluable ... thanks again! This is now fixed in SVN revision 520.

Changed November 02, 2006 11:43PM UTC by Steve O comment:11


Many thanks, this one really helps out.


Changed October 11, 2009 02:13PM UTC by dmethvin comment:12

component: → ajax
need: → Review
priority: → blocker
resolution: → fixed
status: reopenedclosed
type: → bug

Reopened by spammer.