[ui5-combobox] Change event is not fired as documented on ui5-combobox

[ixiler]

Bug Description

All the descriptions bellow are about ui5-combobox component
The change event doesn't fire when the value in the input matches a ui5-cb-item text attribute exactly. In such case the event is not fired when the ui5-cb-item is clicked, when the Enter button is pressed and when the input is focused out.

Expected Behavior

The change event to fire as per the documentation description "Fired when the input operation has finished by pressing Enter, focusout or an item is selected.".
A temporary workaround would be appreciated as well, since using selection-change events fires before the user interaction is finished (pressing enter, clicking on a ui5-cb-item or focusing out). The Enter press and focus out already have workarounds on our end, but couldn't catch the ui5-cb-item event.

Steps to Reproduce

1. Go to the sandbox
2. Enter Item1 into the combo box
3. Press Enter
4. Observe that the event is not fired, the Selected value is not updated in the designated span and no log is present in the console.
5. The Item1 value should still be present in the input. Open the dropdown.
6. Click on Item1
7. Observe that the event is not fired, the Selected value is not updated in the designated span and no log is present in the console.
8. Focus the input
9. Focus out the input
10. Observe that the event is not fired, the Selected value is not updated in the designated span and no log is present in the console.

Isolated Example

The sandbox provided is a simple one: There is a single combobox with 3 items and a span above it that is changed by the events fired by the change event. Also the subscription to the change event logs the received value to the console.
sandbox

Context

• UI5 Web Components version: {1.4.0}
• OS/Platform: {any}
• Browser: {any}
• Affected component: {ui5-combobox}

Log Output / Stack Trace / Screenshots

Priority

• Low
• Medium
• High
• Very High

The priority indicates the severity of the issue. To set the appropriate priority consider the following criteria:

• Breaks entire application or system - High or Very High
• Accessibility issue - Medium or High
• Functional issue - Medium or High
• Visual issue - Low or Medium

Note: The priority might be re-evaluated by the issue processor.

Stakeholder Info (if applicable)

• Organization: {SAP}
• Unit: {Automation Pilot}
• Business impact: {Customers already complain that the data they enter is not updated on form submit}

[ilhan007]

Hi @SAP/ui5-webcomponents-topic-rl @nikolay-kolarov any workaround available while we tackle the issue would be appreciated.

[nnaydenow]

Hi @SAP/ui5-webcomponents-topic-rl,

Issue is reproducible and you can reproduce it as author describes it. It is reproducible only if the input's text match whole item text.

Regards,
Nayden

[d3xter666]

Hi @ixiler ,

You'd need to use the ui5-change event. The change event comes from the browser and is a native event. We're not touching those events. But for the sake of business correctness, we have introduced the ui5-* custom events.
As selection in the Combobox is quite specific, the correct behavior comes with ui5-change.

Cheers

[ixiler]

Hi @d3xter666,

For what version of the web components is that true? I tried to modify the sandbox with the proposed event and it does not work as expected - the bug is still reproducible. Can you provide a working example?

Also is that a general rule that all documented events are expected to have ui5- prepended to them in order to work as documented?

Cheers

[pskelin]

the ui5- event prefix is only useful when the original event is somehow colliding with a 3rd party library or becomes a standard browser event in the future. In such cases, the firing of the documented event can be disabled via the noConflict configuration as described here:
https://github.com/SAP/ui5-webcomponents/blob/main/docs/2-advanced/01-configuration.md#noconflict

Other than that, the original event name as documented should be used and should have the same behaviour as the prefixed one.

@d3xter666 please double check if this is the intended behaviour of the event.

[d3xter666]

Thanks! Would recheck it