1574160 - Don't let the user enter invalid values into <input type="number">

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect, P3)

Description

[Joe Bop]

Attachment: demo.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

<input type="number" required>

Give it the value "q", "one", "1a", or other string that is not wholly numeric.

Actual results:

ValidityState of the element has badInput: true and valueMissing: true.

Expected results:

ValidityState of the element should have badInput: true and valueMissing: false.

Comment 1

[Joe Bop]

An alternative solution is that all non-numeric characters simply cannot be entered in the field. I believe this is the way it works in chromium.

Comment 2

[Henri Sivonen (:hsivonen)]

ValidityState of the element should have badInput: true and valueMissing: false.

My understanding of the spec is that this is correct.

Comment 3

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

The behavior is according to the spec. It contains

A control's value is its internal state. As such, it might not match the user's current input.

The examples of the spec contain:

For instance, if a user enters the word "three" into a numeric field that expects digits, the user's input would be the string "three" but the control's value would remain unchanged.

Moreover another part of the spec states:

valueMissing

    The control is suffering from being missing.

Which is defined as:

Suffering from being 

When a control has no value but has a required attribute (input required, textarea required);

Comment 4

[Joe Bop]

While I agree with the previous comment (#3 Mirko), I believe this does not invalidate the bug report, but would merely switch it the other way round.

Instead of:

Expected results:

ValidityState of the element should have badInput: true and valueMissing: false.

It should then be:

Expected results:

ValidityState of the element should have badInput: false and valueMissing: true.

This is because, as per the [same page for valueMissing's definition](given https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-validitystate-badinput), we have badInput defined as

badInput

The control is suffering from bad input.

Or, in further detail,

Suffering from bad input

When a control has incomplete input and the user agent does not think the user ought to be able to submit the form in its current state.

Now, due to the vagueries of the English language, "incomplete input" could mean many things, including that the control value is missing. However, if it does, then we still have a bug. That is, when the value is actually missing (i.e., nothing has been entered by the user) and therefore the control value is also missing, we get:

{
valueMissing : true
typeMismatch : false
patternMismatch : false
tooLong : false
tooShort : false
rangeUnderflow : false
rangeOverflow : false
stepMismatch : false
badInput : false
customError : false
valid : false
}

So, assuming this is correct, as semantically it obviously should be, we have to exclude the idea that badInput includes the control value being missing.

Thus, by the previous derivation of the spec, we should never have a situation where there is badInput : true for a number field.

(Notably, badInput is false when stepMismatch, rangeUnderflow, or rangeOverflow are true, btw).

Of course, this is a bit of a nonsense and demonstrates that the spec is out of line with expectations for the vast majority. A situation where a user inputs "qwerty" in a number field is not semantically a case of valueMissing (neither to the user nor any website developer), it is a case of badInput (or, preferably in my opinion, typeMismatch).

---

There are three solutions as far as I can see:
1)

• when no value is entered by the user - badInput : true and valueMissing : true
• when invalid characters, etc. are entered - badInput : true and valueMissing : true

• when no value is entered by the user - badInput : false and valueMissing : true
• when invalid characters, etc. are entered - badInput : true and valueMissing : false

• when no value is entered by the user - badInput : false and valueMissing : true
• when invalid characters, etc. are entered - badInput : false and valueMissing : true

As opposed to our current:

• when no value is entered by the user - badInput : false and valueMissing : true
• when invalid characters, etc. are entered - badInput : true and valueMissing : true

I think both (1) and (3) can be interpreted as following spec, but clearly (2) should be the correct answer and the spec should reflect that.

---

P.S. For what it's worth, spec-wise, I can't think of a situation where badInput is useful to validityState, why aren't these situations covered by typeMismatch?

Comment 5

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Joe, thanks for analyzing the issue in more depth. As @annevk pointed out on a different communication channel, the part of the spec we've been looking at is non-normative:

(The definitions below are non-normative; other parts of this specification define more precisely when each state applies or does not.)

In this case, the constraint validation of <input type="number"> covers this:

Constraint validation: While the user interface describes input that the user agent cannot convert to a valid floating-point number, the control is suffering from bad input.

Changing typeMismatch nowadays seems impossible, because it would be a breaking change and apparently this has been specified already for a decade.

I'll close the bug. Feel free to reopen it if I missed something.

Comment 6

[Joe Bop]

Thanks for having a deep look through the spec to find this. I agree that the quote does invalidate this bug.

As I understand it now, there shouldn't be a situation where badInput is true without valueMissing also being true. This is because the badInput boolean relates to the user agent's capacity to convert the user interface value rather than anything to do with it's underlying control value (which, naturally, would remain empty in the case of badInput). Am I right in this?

I will file a bug with whatwg to try to get the definition of "suffering from bad input" changed to more accurately reflect it's actual nature.

Cheers for your help.

Comment 7

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

(In reply to Joe Bop from comment #6)

Thanks for having a deep look through the spec to find this. I agree that the quote does invalidate this bug.

As I understand it now, there shouldn't be a situation where badInput is true without valueMissing also being true. This is because the badInput boolean relates to the user agent's capacity to convert the user interface value rather than anything to do with it's underlying control value (which, naturally, would remain empty in the case of badInput). Am I right in this?

Yes. For valueMissing and required: Constraint validation: If the element is required, and its value IDL attribute applies and is in the mode value, and the element is mutable, and the element's value is the empty string, then the element is suffering from being missing.

I will file a bug with whatwg to try to get the definition of "suffering from bad input" changed to more accurately reflect it's actual nature.

Cheers for your help.