Datepicker: "destroy" method leaves behind the generated id attribute

[willpall]

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.

[tj.vantoll]

Confirmed. This should be fixed when we switch to using uniqueId and removeUniqueId with the rewrite.