Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Select2 now clears the internal ID when it is destroyed #5587

Merged
merged 1 commit into from Jul 28, 2019
Merged

Conversation

kevin-brown
Copy link
Member

This pull request includes a

  • Bug fix
  • New feature
  • Translation

The following changes were made

  • Remove the data-select2-id attribute when RemoveData is called
  • Add some tests for `RemoveData

If this is related to an existing ticket, include a link to it as well.

Fixes #5247

This fixes a bug where if you cloned a Select2, the internal ID used
for mapping elements (specifically the `<select>`) to the in-memory
data store would be cloned as well, causing issues when you tried to
initialize Select2 on the cloned element. This was because we did not
properly clear all of the internal data and all of the internal
attributes that Select2 uses when we destroyed it. The internal
`data-select2-id` attribute was not being cleared, and this was the
attribute being used for the internal mapping.

Now we properly clear the `data-select2-id` attribute from the element
when we call `RemoveData` on the element. This aligns with what we
were trying to do, since we previously cleared out the internal store
for that ID, and fixes the issue we were seeing when cloning.

Fixes #5247
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Versions newer than v4.0.3 seem to have issues when destroy/cloning select2's
1 participant