967429 - input type=number should not throw away unrecognized input on up/down arrow click

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[B.J. Herbison]

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.

Comment 1

[Jonathan Watt [:jwatt]]

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).

Comment 2

[Jonathan Watt [:jwatt]]

Attachment: patch

Comment 3

[Jonathan Watt [:jwatt]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a0927d0558b

Comment 4

[[Back August 16] Ryan VanderMeulen]

https://hg.mozilla.org/mozilla-central/rev/1a0927d0558b

Comment 5

[Jonathan Watt [:jwatt]]

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

Comment 6

[Jonathan Watt [:jwatt]]

(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.

Comment 7

[Jonathan Watt [:jwatt]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e3626652c8b0