Opened 10 years ago

Last modified 9 years ago

#9410 open bug

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.

Change History (2)

comment:1 Changed 10 years ago by tj.vantoll

Component: ui.coreui.datepicker
Status: newopen
Summary: Datepicker "destroy" method leaves behind the generated IDDatepicker: "destroy" method leaves behind the generated id attribute

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

comment:2 Changed 9 years ago by Scott González

Keywords: rewrite added
Note: See TracTickets for help on using tickets.