NumberField - invalid value stored in formData when working with decimal numbers that use `,` for decimal point

[BTMPL]

Prerequisites

• I have searched the existing issues
• I understand that providing a SSCCE example is tremendously useful to the maintainers.
• I have read the documentation
• Ideally, I'm providing a sample JSFiddle, Codesandbox.io or preferably a shared playground link demonstrating the issue.

What theme are you using?

antd

Version

5.x

Current Behavior

The issue can be reproduced in the RJSF playground, https://rjsf-team.github.io/react-jsonschema-form/, by changing to the "number" examples.

When the user enters a numerical value followed by a dot, the value from formData is removed completly.

Looking at the NumberField.tsx code (https://github.com/rjsf-team/react-jsonschema-form/blob/main/packages/core/src/components/fields/NumberField.tsx) there's some special handling for such cases:

/**
 * The NumberField class has some special handling for dealing with trailing
 * decimal points and/or zeroes. This logic is designed to allow trailing values
 * to be visible in the input element, but not be represented in the
 * corresponding form data.
 *
 * The algorithm is as follows:
 *
 * 1. When the input value changes the value is cached in the component state
 *
 * 2. The value is then normalized, removing trailing decimal points and zeros,
 *    then passed to the "onChange" callback
 *
 * 3. When the component is rendered, the formData value is checked against the
 *    value cached in the state. If it matches the cached value, the cached
 *    value is passed to the input instead of the formData value
 */

but from my understanding of point 2 the normalized value should be stored in in the formData object, which is not the case.

Expected Behavior

Proper value is saved in the formData state.

Steps To Reproduce

1. Navigate to the RJSF e=playground and change to the "Numbers" example
2. Type "123" in the "Number" field
3. formData properly reflects the change
4. Type "123." in the "Number" field
5. formData no longer holds the value form the field

Environment

Anything else?

No response

[heath-freenome]

@BTMPL Per your steps to reproduce, I went to the Number example and could not reproduce using Chrome. What browser are you using?

[BTMPL]

Maybe there's an error in my description, but I can reproduce this on Chrome Macos, Firefox Macos, Firefox Win32

Notice how the first field has "666." in it, but the object in "formData" doesn't hold the value at all.

[heath-freenome]

@BTMPL Here's my screenshot from macos (Sequoia 15.6.1) chrome (140.0.7339.81 (Official Build) (arm64))... So clearly something is different in your world. What version of MacOs and Chrome?

[nickgros]

On my particular instance of Firefox/Linux, I can type one dot and the formData doesn't change. When I type a second, the property goes away as described.

The behavior of a type="number" field can vary between OSes and browsers, so if you need specific behavior, you may just want to use a text widget or custom widget:

See also, Why the GOV.UK Design System team changed the input type for numbers

[heath-freenome]

On my particular instance of Firefox/Linux, I can type one dot and the formData doesn't change. When I type a second, the property goes away as described.

The behavior type="number" field can vary between OSes and browsers, so if you need specific behavior, you may just want to use a text widget or custom widget:

See also, Why the GOV.UK Design System team changed the input type for numbers

Same for me with Firefox (125.0.1) on mac os:

[BTMPL]

Interesting.

Macos 15.6.1, Chrome, 139.0.7258.155
Macos 15.6.1, Firefox, 142.0

Maybe it's locale specific? I'm using Polish locale, according to my settings the decimal separator is ,.

[heath-freenome]

Interesting.

Macos 15.6.1, Chrome, 139.0.7258.155 Macos 15.6.1, Firefox, 142.0

Maybe it's locale specific? I'm using Polish locale, according to my settings the decimal separator is ,.

If you use , instead of ., does it work? I can't even enter , using Chrome.

[BTMPL]

Yes, I have the same behaviour as @nickgros reported:

Additionally, RJSF will transform , into . for the stored value:

[heath-freenome]

So can we resolve this as not a bug given it was a locality issue?

[BTMPL]

Well, I would still love to have "66" stored if user types "66."/"66," into the form, but if it's not stored by design I'm OK with closing this ticket. But this looks to contradict the comment in the file I referenced:

• 2. The value is then normalized, removing trailing decimal points and zeros,
• then passed to the "onChange" callback

The onChange handler is called with undefined (can't verify now, but I'm 99% sure that's the case).

[heath-freenome]

@BTMPL Sorry for the late reply... Looking at the NumberField code it seems that the hard-coded use of . in the two RegEx's and one conditional is NOT localization aware. Are you willing to update the component to use the Intl.NumberFormat.formatToParts API to pick up the correct decimal point and use that instead? You should be able to use the navigator.languages API to get the primary locale to use (and default to en) if there are no choices.