Describe the bug
When incrementing or decrementing the value of a NumberField via the respective buttons or the scroll wheel,
while using a locale that uses a different decimal seperator than . (e. g. German uses ,),
the decimal seperator is removed and the incremented/decremented number is shown as the resulting integer.
Enter the text 1,1 (German notation for the number 1.1).
Click the increment button.
The NumberField now shows 21.
Expected behavior
The NumberField shows 2,1.
Screenshots
Before increment:
After increment:
Desktop (please complete the following information):
OS: Arch Linux
Browser: Firefox
Version: 123.0 (64-bit)
Additional context
After some debugging, I think the problem is in these two lines or rather, their behavior. The first sets the value to the (number) 2.1. The second then tries to format that value. While doing so, it parses the value, where the number2.1 is treated as a string and passed to the numberParser. That in turn throws away the decimal point, because in German, it's the grouping character (1234.5 is written as 1.234,5). Thus, the format function formats the value 21.
One solution might be to change this line to local.format && typeof value !== "number". That way, if a value is already a number, it doesn't get parsed again. In the bug above, that would mean the number2.1 is preserved and it should solve the problem. Although I'm not sure whether my proposal breaks other functionality.
Related Problems
While testing, I found a very similar problem. I could turn it into its own issue, but I think it's similar enough that it's better to quickly describe it here: When setting rawValue to a value with a decimal point (e. g. 1.1), it gets shown as 11 using the German locale. I think this bug should be fixed by the one-line modification above.
Describe the bug When incrementing or decrementing the value of a
NumberFieldvia the respective buttons or the scroll wheel, while using a locale that uses a different decimal seperator than.(e. g. German uses,), the decimal seperator is removed and the incremented/decremented number is shown as the resulting integer.To Reproduce Steps to reproduce the behavior:
NumberField.1,1(German notation for the number1.1).NumberFieldnow shows21.Expected behavior The
NumberFieldshows2,1.Screenshots Before increment:
After increment:
Desktop (please complete the following information):
Additional context After some debugging, I think the problem is in these two lines or rather, their behavior. The first sets the
valueto the (number)2.1. The second then tries to format that value. While doing so, it parses the value, where thenumber2.1is treated as astringand passed to thenumberParser. That in turn throws away the decimal point, because in German, it's the grouping character (1234.5is written as1.234,5). Thus, theformatfunction formats the value21.One solution might be to change this line to
local.format && typeof value !== "number". That way, if a value is already anumber, it doesn't get parsed again. In the bug above, that would mean thenumber2.1is preserved and it should solve the problem. Although I'm not sure whether my proposal breaks other functionality.Related Problems While testing, I found a very similar problem. I could turn it into its own issue, but I think it's similar enough that it's better to quickly describe it here: When setting
rawValueto a value with a decimal point (e. g.1.1), it gets shown as11using the German locale. I think this bug should be fixed by the one-line modification above.