[UWP] Number less than the min returned in Input.Number when user input is more than double precision

[RebeccaAnne]

Platform

What platform is your issue or question related to? (Delete other platforms).

• UWP

Details

Using the card below, which has a min of 2.5, if the user inputs 2.4999999999999999, the validation passes and "2.4999999999999999" is returned as the value. Javascript and .NET also pass validation in this case, but both of those platforms return "2.5" in the submit (.NET updates the value in the UI to 2.5 as well). The JavaScript/.NET behavior is probably better here as we ideally don't want to send back number values technically less than the passed in min.

(I haven't tested the iOS/Android behavior)

Input.Number.Float.json:

{
	"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
	"type": "AdaptiveCard",
	"version": "1.3",
	"body": [
		{
			"type": "Input.Number",
			"id": "number",
			"label": "Enter a number between 2.5 and 9.5",
			"min": 2.5,
			"max": 9.5,
			"value": 4.5,
			"errorMessage": "Invalid input. Ensure it's between 2.5 and 9.5, inclusive."
		}
	],
	"actions": [
		{
			"type": "Action.Submit",
			"title": "OK"
		}
	]
}

[golddove]

You could argue that it's preferable to leave the user input as-is, and let the bot consume it however it wishes (think: maybe a bot would like to support greater precision in their inputs. if we force-round the input, the bot is stuck with the precision we choose).

Whichever we think is the right behavior, I agree platforms should be consistent.

[RebeccaAnne]

You could argue that it's preferable to leave the user input as-is, and let the bot consume it however it wishes (think: maybe a bot would like to support greater precision in their inputs. if we force-round the input, the bot is stuck with the precision we choose).

I don't necessarily disagree with that, but in that case we'd ideally want to enforce the min/max without rounding. So our choices are:

1. Do the number comparisons via conversion to double, but send the user data as is, violating the min (current UWP behavior)
2. Do the number comparisons via conversion to double, and return the rounded value, reducing precision for the bot (current .NET/JavaScript behavior)
3. Write some code to do the number comparisons on the string without converting the string to a number.

3 seems like more trouble than it's worth for this edge case. I'm comfortable with the idea that Input.Number doesn't support greater than double precision (unless someone is asking for it), especially given several of our platforms didn't do better than int until recently. And I think 2 is better than 1. Also, for what it's worth, the .NET xceed control is doing the rounding itself before we get a chance to intervene anyway.

[jonmill]

Dupe of / will be fixed by #5404