Describe the bug
When two ComboBox items have different value props but their display text normalizes to the same string (due to newline characters being collapsed by HTML input elements), the onChange event does NOT fire when using keyboard navigation (arrow keys + Enter) to switch between them.
Mouse click on the same item works correctly and fires onChange.
Root cause hypothesis: The ComboBox internally compares the input element's text value before/after to decide whether to emit onChange. Since HTML <input> elements normalize \n to spaces, two items like "Line1\nLine2" and "Line1\n\nLine2" both render as "Line1 Line2" in the input — so the component thinks nothing changed and suppresses the event.
The selectedValue prop IS different between the items, but onChange still doesn't fire because the text-level comparison short-circuits.
Related: #12062 (same underlying normalization issue, but this specific keyboard-vs-mouse behavioral difference was not raised there)
Isolated Example
https://stackblitz.com/edit/github-pmhxdqgs?file=src%2FApp.tsx,package.json
Reproduction steps
-
Create a ComboBox with items whose text contains newline characters that normalize to the same display string, e.g.:
- Item id=2:
text='test "/() est' value="2"
- Item id=3:
text='test "/()\n\ntest' value="3"
Item 3 normalizes to the same display text as Item 2 in the HTML input (newlines become spaces).
-
Select Item 2 (test "/()test) by clicking it (mouse) — onChange fires correctly.
-
Now open the dropdown again, use arrow keys to navigate to Item 3 (test "/()\n\ntest), press Enter.
-
Expected: onChange fires with selectedValue="3"
Actual: onChange does NOT fire. The input text appears unchanged (both items display identically after newline normalization), so the event is suppressed.
-
If instead of keyboard you click Item 3 with the mouse in step 3, onChange fires correctly.
StackBlitz repro: https://stackblitz.com/edit/github-pmhxdqgs?file=src%2FApp.tsx,package.json
Expected Behaviour
onChange should fire whenever the user commits a selection (via keyboard Enter or mouse click) that results in a different selectedValue, regardless of whether the normalized display text appears identical.
The event decision should be based on selectedValue (the machine-readable identifier), not on the rendered input text — which is lossy due to HTML input newline normalization.
Screenshots or Videos
No response
UI5 Web Components for React Version
2.22.0 & the latest
UI5 Web Components Version
2.22.0 & the latest
Browser
Chrome
Operating System
macOS 15
Additional Context
This was discovered while fixing a real-world issue where activity names in SAP SuccessFactors contain newline characters. We migrated from text-based comparison to value/selectedValue API (per recommendation in #12062), which fixes the mouse-click path. However the keyboard path remains broken.
The inconsistency between mouse and keyboard behavior suggests the bug is in the ComboBox commit logic:
- Mouse click: presumably bypasses the text-comparison check and directly selects the item
- Keyboard Enter: appears to check whether the input text value changed, and suppresses
onChange if it did not
Since the value/selectedValue API was introduced specifically to decouple item identity from display text, the onChange emission logic should also use selectedValue (not display text) to determine whether the selection actually changed.
Relevant log output
Organization
SAP
Declaration
Describe the bug
When two ComboBox items have different
valueprops but their displaytextnormalizes to the same string (due to newline characters being collapsed by HTML input elements), theonChangeevent does NOT fire when using keyboard navigation (arrow keys + Enter) to switch between them.Mouse click on the same item works correctly and fires
onChange.Root cause hypothesis: The ComboBox internally compares the input element's text value before/after to decide whether to emit
onChange. Since HTML<input>elements normalize\nto spaces, two items like"Line1\nLine2"and"Line1\n\nLine2"both render as"Line1 Line2"in the input — so the component thinks nothing changed and suppresses the event.The
selectedValueprop IS different between the items, butonChangestill doesn't fire because the text-level comparison short-circuits.Related: #12062 (same underlying normalization issue, but this specific keyboard-vs-mouse behavioral difference was not raised there)
Isolated Example
https://stackblitz.com/edit/github-pmhxdqgs?file=src%2FApp.tsx,package.json
Reproduction steps
Create a ComboBox with items whose
textcontains newline characters that normalize to the same display string, e.g.:text='test "/() est'value="2"text='test "/()\n\ntest'value="3"Item 3 normalizes to the same display text as Item 2 in the HTML input (newlines become spaces).
Select Item 2 (
test "/()test) by clicking it (mouse) —onChangefires correctly.Now open the dropdown again, use arrow keys to navigate to Item 3 (
test "/()\n\ntest), press Enter.Expected:
onChangefires withselectedValue="3"Actual:
onChangedoes NOT fire. The input text appears unchanged (both items display identically after newline normalization), so the event is suppressed.If instead of keyboard you click Item 3 with the mouse in step 3,
onChangefires correctly.StackBlitz repro: https://stackblitz.com/edit/github-pmhxdqgs?file=src%2FApp.tsx,package.json
Expected Behaviour
onChangeshould fire whenever the user commits a selection (via keyboard Enter or mouse click) that results in a differentselectedValue, regardless of whether the normalized display text appears identical.The event decision should be based on
selectedValue(the machine-readable identifier), not on the rendered input text — which is lossy due to HTML input newline normalization.Screenshots or Videos
No response
UI5 Web Components for React Version
2.22.0 & the latest
UI5 Web Components Version
2.22.0 & the latest
Browser
Chrome
Operating System
macOS 15
Additional Context
This was discovered while fixing a real-world issue where activity names in SAP SuccessFactors contain newline characters. We migrated from text-based comparison to
value/selectedValueAPI (per recommendation in #12062), which fixes the mouse-click path. However the keyboard path remains broken.The inconsistency between mouse and keyboard behavior suggests the bug is in the ComboBox commit logic:
onChangeif it did notSince the
value/selectedValueAPI was introduced specifically to decouple item identity from display text, theonChangeemission logic should also useselectedValue(not display text) to determine whether the selection actually changed.Relevant log output
Organization
SAP
Declaration