Description
A number > 12345678901234567 can be entered in User Interface, integer or decimal type.
But using the spinner will create problems then: last digit (posion 17) is changed by one, then spinner doesn’t work any more.
More digits than defined for the types can be entered and create strange behaviour.
Steps to Reproduce
-
Use attached XLSForm
numSpinner01.xlsx (9.9 KB) -
Preview form with Online validator or KoboToolbox (Enketo)
-
Enter 12345678901234567 in Score01 field (17 digits) and click
-
See following textual and numeric field for monitoring: Wrong, shows 12345678901234568
-
Use spinner down (or up): Value changes to 12345678901234568 (even if spinner down!)
-
Use spinner down (or up): No more reaction!
-
See following textual and numeric field for monitoring: No changes.
-
Manually reduce (last digit) number to 12345678901234561
-
See following textual and numeric field for monitoring: Wrong, shows 12345678901234560
Similar behaviour if you use Score02 (decimal type). In addition very long numbers get padded with zeros.
Expected behavior
User Interface should not allow numbers greater than valid for the type.
Entered numbers should not been changed.
And spinner should work correctly (up and down).
Actual behavior
Screen after entering digit 7 (position 17). and click.
Stored data, with internally changed digit (position 17) from 7 to 8.
This change also seems to happen if saved as draft and re-load.
Additional details
Preview with Online validator. Firefox newest version 113.0.2, Windows 10 Pro, XLSForm.
Same with preview and with deploy and open on KoboToolbox Server (OCHA).
Similar problems with Google Chrome, newest Version 113.0.5672.127,
I remember there were some problem postings around number precision in this forum, which might be related.
For length imits for numeric types see Number, Decimal and Range Question Types — KoboToolbox documentation.
