Datepicker: "destroy" method leaves behind the generated id attribute
|Reported by:||willpall||Owned by:|
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.
Change History (2)
comment:1 Changed 4 years ago by tj.vantoll
- Component changed from ui.core to ui.datepicker
- Status changed from new to open
- Summary changed from Datepicker "destroy" method leaves behind the generated ID to Datepicker: "destroy" method leaves behind the generated id attribute