Numeric answer validation doesn't detect shorter non-numeric strings

[deundrewilliams]

When entering a non-numeric answer for a numeric question, a form validity element should show saying 'Not a valid numeric value' when trying to leave focus. This seems to work, but only for strings with at least 7 characters.

This also still allows saving which results in a blank screen error when opening the viewer, but this part should be fixed with #2027

[deundrewilliams]

Looking at this more, it seems like saving doesn't cause a blank screen error in the viewer if the string is less than 7 characters, but the assessment grading then tries to take a margin of error of a string.

[zachberry]

The input tries to do some guessing on what you mean - it may be interpreting abcdef as hex (as in 0xABCDEF). I would try xyz as a three letter input and see if that has the same result.

[deundrewilliams]

@zachberry Oh that makes sense, trying xyz does result in the blank screen error instead, so it's probably interpreting it in hex

[FrenjaminBanklin]

Given the description of the issue and the knowledge that hex values are valid numeric answers, I'm not sure if there's really an 'issue' here per se.

I could see taking the 'valid inputs' tooltip from the viewer side and also placing it in the editor side so authors are immediately aware of what constitutes valid input for a numeric answer, but I'm not sure if there's anything necessary beyond that. Changing what counts as 'valid' at this point seems like it would cause breakage in existing content, so I wouldn't consider that an option.

@zachberry Curious if you think there's anything else we can or should do here. I'm hesitant to mess with the numeric validation code at all, but perhaps it would be possible to change the input in some way to indicate when a provided value is being identified as 'hexadecimal', since it's otherwise not obvious why 'xyz' is invalid but 'abc' isn't.

[zachberry]

@FrenjaminBanklin The eventual plan was to expose some options in the editor to let authors specify what types of input they expect - there's code to define that in the system but no UI to do so. I'm not sure how the bug came up, but personally I would let it ride as I would expect 'abc' not to be a common answer in a real assessment (just in cases where a dev or instructor is filling in dummy data, although I get that the result shown is confusing).

It would be possible to change the default so that it doesn't try to guess at hex-like strings and would require the prefix always (0x or #). Technically that would break existing behavior but I'm guessing adoption for numeric questions may be small enough for now that there's no instructors using it for hex, octal or binary input. The reason it does guessing (or at least the thought behind the idea) was for cases where an instructor creates a CS question that expects the student to answer in hex - in that case, they'd be able to (for example) just answer as 0F0A and not get the answer rejected as invalid because they forgot to prefix it with 0x. But the result shown here in current usage probably happens way more often. If you are interested in changing that let me know and I can review the code (it's been a while), and give out some pointers on how it'd be done.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep our backlog under control, but we thank you for your contributions.