NumberInput: Deleting Number with Comma via Backspace

[texttechne]

Describe the bug
Preconditions:

• <Input type="Number" />
• use comma, e.g. 12,50

Use Case:
When the whole number is selected, then deleting the value via back space will preserve the part before the comma: "12,50" => "12"
Works with dot as separator, works with pure integers, but not with comma separated fractions.

Isolated Example
Example

To Reproduce
Steps to reproduce the behavior:

1. Mark the whole number
2. press back space

Expected behavior
Consistent behaviour! The complete number should be deleted, like it is done in any other case.

[MarcusNotheis]

Thanks for reporting! I'll forward this issue to our UI5 Web Components Colleagues as the affected component is developed in their repository.

[IlianaB]

Hello @SAP/ui5-webcomponents-topic-rl I am forwarding this issue to you, because deleting number with comma separator via BackSpace does not delete the whole number, but only the fractional part, as opposed to deleting a number with dot separator.

Regards,
Iliana

[ilhan007]

Hello @SAP/ui5-webcomponents-topic-rl

Some help with the investigation:

There is some interesting issues of the native inputs from type number upon deleting a number:

• Example1: type "123.4" and press BACKSPACE - the native input is firing event with empty value.
• Example2: type "123.456", select/mark "456" and press BACKSPACE - the native input is firing event with empty value.
• Example3: type "123.456", select/mark "123.456" and press BACKSPACE - the native input is firing event with empty value, and only this time it's really the case.

For the first and the second examples we have some code to overcome this behaviour.
But, the author's use case is the last example, when the entire number is selected and BACKSPACE is used. Now we expect to have an empty field, but end up with the whole part of the number(without the fraction) restored - see the provided codesandbox.

And, as you will notice it is working for ".", but not for ",".
The root cause is that the condition that you can find on line 799

    if (rgxFloat.test(this.value) && this._selectedText !== this.value) {

more specifically the second part of the condition is true, but we expect it to be false

 "this._selectedText !== this.value"  // 13,33 !== 13.33

Although you type "13,33" in the input the "value" property is "13.33" and when we reach the above condition, the two are different and the code restores the whole part of the number "13" as it should do for Example 1 and 2 cases, and should not in the is case. I guess this is again some specialty of the input of type number, and also might be affected by OS/Browser localisation settings as far as I know. You can investigate further and look for some know solutions, but what comes to mind is to (1) treat 13,13 and 13.13 as same in the condition or (2) make sure that this.value has the value of what is really typed in.