- My goal: Disallow values outside the specified min & max.
- Issue: Using "shift" modifier while using up & down arrow keys to increase the increment level allows the bounds to be temporarily violated until input is blurred.
- Steps I've taken to troubleshoot: tried different input methods e.g. clicking, arrow keys, arrow keys + modifier (shift)
- Additional info: (Cloud or Self-hosted, Screenshots)
As the violated values get clamped to the min and/or max on input blur, this isn't that bad of an issue, especially because a form using such an input would naturally obey the validation due to the inherent blurring required before submission.
But it's inconsistent with other input methods and can have temporary, bad side effects for other components or processes which use the real-time value.
For example, if any event handlers use the existing value as a conditional, additional scope, etc, or, say, are referenced as a coordinate on a MapBox component or similar, you could easily end up with bad downstream effects or a non-sensical preview.
I realize that the "temporary" value of one of these inputs can violate validation when values are input directly with number keys (e.g. you can easily input "10" when the max is set to "9").
But because the arrow keys obey the min & max on their own (as do the stepper buttons when clicked), I feel the shift-key approach should be consistent with that. The result being one less "loophole" for value violation.
Video example [when the numbers go above & below in increments of 10, that's when I'm using the shift key]:
Example app JSON:
temp for input validation bug report.json (6.1 KB)
As soon as I have news to share, I'll do so here.