Closed Bug 967429 Opened 6 years ago Closed 6 years ago
input type=number should not throw away unrecognized input on up/down arrow click
Don't throw away user input. The current behavior is to *sometimes* throw away user input, but inconsistently. Invalid numbers are preserved, but valid numbers incorrectly formatted are thrown away. Be more flexible about accepting numbers. Steps to reproduce: 1) Enter "102" in an input type=number field with a minimum of 10 and a maximum of 100. 2) Press up arrow. 3) Enter "abc" in an input type=number field with a minimum of 10 and a maximum of 100. 4) Press up arrow. 5) Press up arrow. 6) Enter "1,2345" in an input type=number field (in a locale where 12,345 is expected). 7) Press up arrow. Actual results: 1) Error indication. 2) Invalid entry is unchanged. 3) Error indication. 4) Invalid entry is erased and replaced with "1" with error indication. (Still invalid, Threw away my typing and didn't even give me a valid input.) 5) "10". The second up arrow converts the input to a valid number. 6) Error indication. 7) Valid but incorrectly formatted number is erased, replaced by "1". Expected results: 2) Current behavior. 4) Error indication (changed highlighting), but "abc" is preserved" 7) Best: "12,346" or "1,2346". Acceptable: "1,2345" with error indication.
Oh, that's some interesting behavior you've uncovered. Thanks for this bug report! I think the best thing to do is probably to make the up/down arrows do nothing if the input is invalid. In the case of step 7, I don't know if it's possible to get the behavior you'd prefer in the generalized localization case. Very possibly we can get the primary (and secondary, if the locale has one) grouping characters from ICU, strip them, and try reparsing. There may be a possibility of different weird results depending on whether we give that operation or falling back to other locales precedence, though. Experimenting with that would be best in a separate bug, I think (I'll file as necessary).
Assignee: nobody → jwatt
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: mozilla29 → mozilla30
Comment on attachment 8374912 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): bug in new feature User impact if declined: bad user experience with number controls on webpages Testing completed (on m-c, etc.): merged to m-c Risk to taking this patch (and alternatives if risky): low risk, early in aurora String or IDL/UUID changes made by this patch: none
Attachment #8374912 - Flags: approval-mozilla-aurora?
(In reply to Jonathan Watt [:jwatt] from comment #5) > Bug caused by (feature/regressing bug #): bug in new feature Bug 344616 if a bug number is needed.
Attachment #8374912 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.