The characters e., can be entered into number widgets with a valueType of int

[papandreou]

- Do you want to request a feature or report a bug?

bug

- What is the current behavior?

The number widget seems to suppress all characters that aren't digits, e, ., +, -, or ,. (I assume the reason why e and + are allowed is to support exponential notation?)

However, these characters are also allowed for number fields with a valueType of int. An attempt is made to sanitize them later, but it doesn't quite work and can lead to the field containing the string .nan.

- If the current behavior is a bug, please provide the steps to reproduce.

1. Add a number field to a collection:

      -
        label: MyNumberField
        name: myNumberField
        widget: number
        valueType: int

2. Create a new item in the collection
3. Enter the text 123e in the field
4. Press 1

Observe that the e disappears and the 1 doesn't get added(?)

5. Press 1 again

Observe that the 1 does get added this time.

6. Press e twice, then 1

Observe that ee is left alone and the content is now 123ee1

7. Click Publish

Observe that the save is rejected with a MYNUMBERFIELD IS REQUIRED. message

8. Change the value to 123..1
9. Click Publish

Observe that the field gets persisted as:

myNumberField: .nan

- What is the expected behavior?

• That ,, ., and e are suppressed when valueType is int. Alternatively that no keystrokes are suppressed and invalid numbers are dealt with when Publish is clicked.
• That an accurate validation error is rendered when an invalid number has been entered
• That garbage like .nan is never persisted :)
• Maybe that e, + and , aren't allowed at all, even when valueType is float or not specified. It seems unlikely that anyone would want to use exponential notation in a CMS.

- Please mention your versions where applicable.

Netlify CMS version: 1.9.2
Browser version: Chrome 67.0.3396.87/OSX

Node.JS version: 10.4.1
Operating System: Mac OSX 10.13.5 (High Sierra)

[erquhart]

The number widget really isn't doing anything here - HTML number inputs accept those characters for scientific notation, and no effort has been made to validate within the CMS. A validation method should be added, perhaps using a library that handles number validation comprehensively rather than reinventing the wheel.

[papandreou]

@erquhart, ah, you're right about <input type=number> causing most of the weirdness. That thing seems terrible :)

[erquhart]

I believe this is addressed in #2067, will release soon.