Skip to main content

Search and Top Navigation

#8964 closed bug (patcheswelcome)

Opened January 15, 2013 12:23PM UTC

Closed April 06, 2013 02:00AM UTC

Datepicker: Memory leak in IE7

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

In jQuery UI 1.9.2 we still see this old problem we've been having since 1.8.14. As soon as the Datepicket widget is included in a web page (minified or not) it will cause the page to leak 10 MB on each refresh. Our only solution so far has been to simply never include the Datepicker widget. We've encountered this issue in tests on IE7, though not in IE9 (not even in compatibility IE7 mode) nor in Firefox.

I'd like to mention that I've seen similar reports to this one that have been marked as duplicates of other tickets, some of which have been marked as fixed or as generalised problems (memory leaks with other widgets). I strongly believe that this is, in fact, not a duplicate, but a separate problem. This issue is strictly about the Datepicker widget and has occurred in 1.8.14, 1.8.16 and 1.9.2 in our tests, leading us to believe this issue has never been solved.

For us it's become impossible to use the Datepicker, because our customers primarily use IE7.

Attachments (0)
Change History (10)

Changed January 15, 2013 04:53PM UTC by tj.vantoll comment:1

owner: → DysprosiumDy
status: newpending

Hi DysprosiumDy, thanks for taking the time to contribute to the jQuery UI project. We're going to need a test case that shows the memory leak in order to look into this. For example, see #8164.

Changed January 30, 2013 09:03AM UTC by trac-o-bot comment:2

resolution: → invalid
status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Changed January 30, 2013 10:03AM UTC by DysprosiumDy comment:3

I request this case to be reopened. I've got a good test case here to reproduce the issue. Apologies that I didn't do this earlier. I did not use jsfiddle because I wanted the page to be as clean as possible. The examples below are therefore hosted on my own server.

Page 1: Datepicker included

Page 2: Datepicker not included

I'm using jQuery 1.8.3 and jQuery UI 1.9.2, but the issue is not limited to these versions as mentioned before. On page 1 you can simply refresh the page using IE7 to see memory usage increase by about 2.5 MB each time. This goes on indefinitely. On page 2 you can do the same and will notice no increase in memory usage.

If you want any additional information, I'll be more than happy to provide it!

Changed February 01, 2013 03:25AM UTC by tj.vantoll comment:4

I'm not seeing anything on those pages other than the jQuery and jQuery UI scripts being included. So the inclusion of the datepicker script itself is causing a leak?

Changed February 01, 2013 09:46AM UTC by DysprosiumDy comment:5

Indeed. We first noticed this problem about a year ago. It took us two days of debugging to discover the source of the memory leak. Our webservice included the datepicker, but didn't use it. We've excluded the datapicker widget ever since. Our customers simply couldn't properly use our service, since they all run IE7.

Changed February 01, 2013 01:59PM UTC by tj.vantoll comment:6

resolution: invalid
status: closedreopened
summary: Memory leak in IE7 with DatepickerDatepicker: Memory leak in IE7

Interesting, I do see the leak. We might be able to close #4188 because this is a far more specific example.

Unfortunately we probably won't get around to fixing until the datepicker rewrite lands in master, although pull requests are welcome.

Changed February 04, 2013 10:01PM UTC by maverick9984 comment:7

Hi All,

How do we get all the instances of datepickers in a page ?

I am using $(window).datepicker("destroy");

But I dont think it will destroy all the controls ?

Any suggestions please ?

Changed February 05, 2013 01:55AM UTC by tj.vantoll comment:8

_comment0: Replying to [comment:7 maverick9984]: \ > Hi All, \ > \ > How do we get all the instances of datepickers in a page ? \ > I am using $(window).datepicker("destroy"); \ > \ > But I dont think it will destroy all the controls ? \ > \ > Any suggestions please ? \ \ maverick9984, \ \ For support use [ Stack Overflow], the[ forums] of #jquery on IRC.1360030310171566

Replying to [comment:7 maverick9984]:

Hi All, How do we get all the instances of datepickers in a page ? I am using $(window).datepicker("destroy"); But I dont think it will destroy all the controls ? Any suggestions please ?


For support use Stack Overflow, the[ forums] or #jquery on IRC.

Changed March 28, 2013 04:04AM UTC by JamesMGreene comment:9

We saw this bug over 1 year ago as well.

When we profiled into it, this is what we found (as nonsensical as it may sound):

  • The memory leak is created by merely included the datepicker definition on the page
  • Once the datepicker definition is included on the page, the use of ANY jQuery UI widget causes memory leakage
  • Strangest of all: if you simply USE the datepicker on the page, the memory leak goes away

In other words, it is only a problem for us in IE7 if the datepicker is included (defined) on the page but is NOT used. Therefore, our workaround is to always keep datepicker as a separate script and only include it on pages where we know we will use it.

IIRC, this is all caused by IE7's shortcoming in the area of not correctly unlinking references to the table elements when they are removed/destroyed from the live DOM... which is why it seems even stranger that the leakage is caused by the definition of the widget rather than the use of it. o_O

Crazy ole IE7....

Changed April 06, 2013 02:00AM UTC by scottgonzalez comment:10

resolution: → patcheswelcome
status: reopenedclosed

At this point, we're not going to spend any more time trying to track this down. Datepicker is being rewritten from scratch, and the new version isn't likely to have whatever problem the current version has. If someone wants to send a pull request, we'll gladly review it.