[Bug]: a form "change" event is fired on blur, when the value did not change

[lovasoa]

Bug description

When the tom select field is blurred, tom select reinitilizes it to an empty state, but still lets a change event bubble up the DOM, while the <select> element value is still the user's search string (that did not match any valid option).

https://github.com/user-attachments/assets/c003a41d-c00a-4baa-9bcf-92ac8e7d0afe

Expected behavior

When the input field is reinitialized, and it was originally empty, then the value did not change, and no change event should bubble up to the parent form component.

Steps to reproduce

1. Go to https://codepen.io/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-/pen/gbOLKKv?editors=1011
2. Start typing something in the input
3. Click outside the input

Additional context

• OS: all
• Browser all
• Version latest
• Device: all

[lovasoa]

initially reported in https://github.com/sqlpage/SQLPage/issues/832

[lovasoa]

Maybe the additional <input> element that tom-select creates to handle user input should not be linked to the same <form> element as the actual <select> that contains the real values selected by the user.

[github-actions[bot]]

This issue has not been active in 120 days and has been marked "stale". Remove stale label or comment or this will be closed in 15 days

[xJuvi]

Hey. This isn't an bug. The documentation says Invoked when the value of the control changes. - the input is the control element. When you enter text, you changed this. So the actual behavior is correct. If you don't want to listen changes on the control element you should use one of these:

• item_select
• item_add
• option_add

Kind regards

[lovasoa]

@xJuvi : This issue about the DOM event that bubbles, not the tomselect-specific event that you can subscribe to with select.on("change", ...).

Which dom events are emitted is not documented anywhere, and I am arguing that the current behavior is makes things harder and a little bit unintuitive for developers.