Re-selecting the currently displayed option does not trigger a change event when control state is desynced from application state

[Rasagnya-Gurrala]

Bug Description

When a Select component's displayed selection is reset to an option (e.g. the first/default item) due to a re-render, but the application's actual filter/state still reflects a previously chosen value, re-selecting that first option does not fire a change event.

This is because the Select considers the first option already selected and treats the user's click as a no-op — no event is emitted, and the consumer's onChange handler is never called.

Steps to Reproduce

1. Render a Select with an initial default option (e.g. "All") and additional options.
2. Select a non-default option — a change event fires and the application state updates correctly.
3. Trigger a re-render that resets the Select's displayed selection back to the default option (without the application state being reset).
4. Click the default option again.

Expected Behavior

Either:

• The Select preserves its displayed selection across re-renders so it always reflects the applied state, or
• A change event is emitted when the user explicitly clicks an option, even if that option is already considered selected by the control.

Actual Behavior

No change event is fired. The consumer's onChange callback is not invoked, and the application state is never updated — leaving the UI showing stale results.

Root Cause (Analysis)

The control's internal selected state diverges from the application's state after a re-render. Because the native change event only fires on an actual selection change,
re-selecting the option the control already considers active is silently swallowed.

Affected Component

No response

Expected Behaviour

No response

Isolated Example

No response

Steps to Reproduce

...

Log Output, Stack Trace or Screenshots

No response

Priority

None

UI5 Web Components Version

2.26.0

Browser

Chrome

Operating System

No response

Additional Context

No response

Organization

No response

Declaration

• I’m not disclosing any internal or sensitive information.

[niyap]

Hello @UI5/ui5-team-ctr-pir,

From my perspective, the described issue is the expected behaviour. However, could you please investigate and analyse it further to determine whether it would be feasible to trigger a change event in such cases?

Thank you in advance!

Kind Regards,
Niya

[NakataCode]

Hello @Rasagnya-Gurrala,

Thanks for the detailed report. After investigating, I also think this is expected behavior rather than a bug.

The change event only fires when the selected option actually changes — the same contract as the native HTML <select>. In your scenario, the re-render resets the Select's displayed selection back to the default option, so the component genuinely considers that option selected. When the user clicks it again, nothing has changed from the component's point of view, so no event is fired. The desync lives in the application state, which the component has no visibility into.

Recommendation: drive the Select through the value property and keep it synchronized with your application state on every re-render. That way the displayed selection always reflects your app state, no desync can occur, and change fires reliably on every real user selection.

I hope this helps — let us know if you need further clarification.

Best regards,
Nikola

[github-actions]

This issue has been closed. To reopen, just leave a comment!