Skip to content

ComboBox: onChange not fired on keyboard select when normalized text is identical #13784

Description

@AlexYanSap1

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

  1. 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).
  2. Select Item 2 (test "/()test) by clicking it (mouse) — onChange fires correctly.

  3. Now open the dropdown again, use arrow keys to navigate to Item 3 (test "/()\n\ntest), press Enter.

  4. 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.

  5. 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

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

Metadata

Metadata

Assignees

Labels

Type

Fields

No fields configured for Bug.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions