Search and Top Navigation
#10629 closed bug (duplicate)
Opened September 29, 2014 07:55AM UTC
Closed September 29, 2014 12:28PM UTC
Last modified September 29, 2014 01:03PM UTC
Datepicker memory leak (_disabledInputs)
Reported by: | olejorgenb | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.core | Version: | 1.11.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
This list is never cleared - so if you disable a datepicker in a single-page-app, the datepicker dom element will leak. (I don't have time to create a nice test case for this right now) Leak observed in version 1.10.2, but looking at the code in 1.11.1 it seems to still be a problem there
Attachments (0)
Change History (3)
Changed September 29, 2014 12:28PM UTC by comment:1
resolution: | → duplicate |
---|---|
status: | new → closed |
Changed September 29, 2014 12:56PM UTC by comment:2
_comment0: | I don't see how it's clear that #9555 is the same issue. I found that issue before creating this one, but didn't see a connection besides the words "memory" and "leak". If the _disabledInput mechanism actually is the cause of the leak in #9555 it might be an idea to update the ticker with that information? (which seems unlikely since that ticker talks about the leak happening just by including jquery ui) → 1411995702073724 |
---|
I don't see how it's clear that #9555 is the same issue. I found that ticket before creating this one, but didn't see a connection besides the words "memory" and "leak". If the _disabledInput mechanism actually is the cause of the leak in #9555 it might be an idea to update the ticker with that information? (which seems unlikely since that ticker talks about the leak happening just by including jquery ui)
Changed September 29, 2014 01:03PM UTC by comment:3
As the other ticket says, unless someone else is going to provide a PR, it doesn't matter. We're already very far into the rewrite of datepicker.
Duplicate of #9555.