Search and Top Navigation
#9410 open bug ()
Opened June 28, 2013 08:58PM UTC
Last modified July 14, 2014 06:42PM UTC
Datepicker: "destroy" method leaves behind the generated id attribute
Reported by: | willpall | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.datepicker | Version: | 1.10.3 |
Keywords: | rewrite | Cc: | |
Blocked by: | Blocking: |
Description
Versions affected: at least jQuery UI 1.9.2+
Browsers affected: Chrome 27, Firefox 20, and probably all others seing the nature of the bug
Operating Systems: Mac OS X 10.7.5 is all I'm able to test
Reproducing the issue:
The issue can be found in this jsfiddle: http://jsfiddle.net/4heNF/1/. It's fairly simple to recreate. First create a Datepicker, then destroy that Datepicker. The elements retain the generated id attribute.
What I expect to happen:
According to the destroy method API documentation (http://api.jqueryui.com/datepicker/#method-destroy), "This will return the element back to its pre-init state." My interpretation would be that this would include removing any id or classes added during the creation of the Datepicker, which is not happening.
While leaving behind an auto-generated id seems innocuous, problems can arise when using already-generated Datepickers as jQuery clone() targets. This means the cloned Datepickers will retain the id and any date selection will update the original input field rather than the cloned ones.
Attachments (0)
Change History (2)
Changed June 28, 2013 09:14PM UTC by comment:1
component: | ui.core → ui.datepicker |
---|---|
status: | new → open |
summary: | Datepicker "destroy" method leaves behind the generated ID → Datepicker: "destroy" method leaves behind the generated id attribute |
Changed July 14, 2014 06:42PM UTC by comment:2
keywords: | → rewrite |
---|
Confirmed. This should be fixed when we switch to using uniqueId and removeUniqueId with the rewrite.