#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 tj.vantoll 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

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

Changed July 14, 2014 06:42PM UTC by scottgonzalez comment:2

keywords: → rewrite