New issue
Advanced search Search tips

Issue 884206 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 21
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-10-05
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

input type number not reporting invalid number according to the specification

Reported by arnaud.b...@gmail.com, Sep 14

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce the problem:
1. Open google.com, search "convert euro to dollar"
2. The result includes a currency converter (input type number) with value='1' and no other attribute (step nor min)

What is the expected behavior?
This field should allow only integer values, since by spec:
https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number)
"The step scale factor is 1. The default step is 1 (allowing only integers to be selected by the user, unless the step base has a non-integer value)."

What went wrong?
The field should only non-integer values.

Firefox behaves "correctly".

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: <Copy from: 'about:version'>  Channel: stable
OS Version: OS X 10.13
Flash Version: Shockwave Flash 22.0 r0

I wasn't sure where to report this, because I believe there is actually 3 issues here:
- google.com's currency converter HTML code is not correct according to the spec.
- since Chrome doesn't implement the specification correctly (IIUC), it looks OK on google.com (but note Firefox doesn't)
- IMHO the specification is bad.

I'm not sure Chrome should be changed, but rather it might be better to try to amend the spec to allow non-integer values (up to a certain precision) without using the step attribute.
A quick fix for google.com would be to use have a step=0.01 attribute, but while this fixes the issue, this is not user friendly on current implementations, since now using the arrow keys will increment the value by only 0.01.
 
Cc: nzolghadr@chromium.org
Components: -Blink>Input Blink>Forms
Cc: tkent@chromium.org
Components: -Blink>Forms Blink>Forms>Number
Labels: Needs-Feedback
NextAction: 2018-10-05
> This field should allow only integer values, since by spec:
> https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number)
> "The step scale factor is 1. The default step is 1 (allowing only integers to be selected by the user, unless the step base has a non-integer value)."

The specification says nothing about UI implementation.  This sentence means: if a user specifies "1.98" to <input type="number" value="1">, input.validity.stepMismatch becomes "true".  The specification doesn't ask UA to prevent users from specifying non-integers.

> Firefox behaves "correctly".

Firefox also accepts non-integers in <input type=number value=1>.

You're right the spec doesn't enforce UI behavior.
I think the issue is probably more on google.com side: it should not set invalid values on this input, since some UA might display something to let the user know it's invalid.
I reported this on the google.com feedback page a few weeks ago, and never heard back.
If you're working at Google, you might report this issue to your colleagues working on that, because this is really not nice.

> Firefox also accepts non-integers in <input type=number value=1>.
but correctly reports the value as invalid, so it's a different issue.
However it's indeed confusing for the user to let him enter characters that will result in an invalid values. I will check if there is a reason why Firefox allows that.
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 21

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
FYI the issue you mentioned is tracked on the Firefox bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1342477

Actually, the main issue with comments from Firefox developers on the rational behind the current implementation is this one: https://bugzilla.mozilla.org/show_bug.cgi?id=1398528

Status: WontFix (was: Unconfirmed)
The different Firefox behavior comes from Firefox's default style (red box-shadow) for vendor-specific :-moz-ui-invalid pseudo class.

Accepting non-integers in integer-only fields should be discussed in Issue 365196.




The NextAction date has arrived: 2018-10-05

Sign in to add a comment