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

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30
Tracking Status
firefox29 + fixed
firefox30 --- fixed

People

(Reporter: bj, Assigned: jwatt)

References

Details

Attachments

(1 file)

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
Flags: needinfo?(jwatt)
Attached patch patchSplinter Review
Attachment #8374912 - Flags: review?(bugs)
Attachment #8374912 - Flags: review?(bugs) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/1a0927d0558b
OS: Linux → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla19
Target Milestone: mozilla19 → mozilla29
https://hg.mozilla.org/mozilla-central/rev/1a0927d0558b
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
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+
Blocks: 344616
You need to log in before you can comment on or make changes to this bug.