1855719 - <input type="number"> returns a blank string to vue.js

Status: RESOLVED INVALID

(Core :: DOM: Forms, defect)

Description

[irina8kats]

Steps to reproduce:

When a user types non-digits in <input type="number">, Firefox allows this (as covered in https://bugzilla.mozilla.org/show_bug.cgi?id=344616).

Yet the input reported to vue.js in this case is an empty string. This can be seen here: https://codepen.io/Divensky/pen/xxmzRYN.

Open this pen in Firefox and type non-numbers in either input. I see a blank line reported by the variable below the input.

Actual results:

The user sees in the browser that they've typed something (some letters in addition to numbers) but under the hood it translates into a blank.

You cannot sanitize this input inside vue.js because you only get a blank input.

Expected results:

The on-screen input and the data relayed to vue.js should be in sync.

Either the user should not be allowed to type any non-numbers into a type="number" input (the way this is done in Chrome), or the input reported to vue.js should match what the user sees on the screen so it can be sanitized.

Comment 1

[Robert Longson [:longsonr]]

Same thing happens in Chrome if I type e or e10 or . or some other invalid string that Chrome allows. Presumably any fix would be within vue.js

Comment 2

[Henri Sivonen (:hsivonen)]

Edgar, what's the correct behavior here?

Comment 3

[Edgar Chen [:edgar]]

Chrome and Safari behaves the same, this behavior is defined in the spec, https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):

The value sanitization algorithm is as follows: If the value of the element is not a valid floating-point number, then set it to the empty string instead.

Comment 4

[irina8kats]

Chrome is seen to set the value to an empty string right there in the browser. Thus the user can see they failed to input the data. This behavior is visible in the pen above.

Firefox seems to set the value to an empty string behind the scenes. The user does not see their input is invalid. Is this really what was intended?

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to irina8kats from comment #4)

Chrome is seen to set the value to an empty string right there in the browser. Thus the user can see they failed to input the data. This behavior is visible in the pen above.

Firefox seems to set the value to an empty string behind the scenes. The user does not see their input is invalid. Is this really what was intended?

Possibly not. Edgar, do we have a reason for not being consistent with the other engines here?

Comment 6

[irina8kats]

Additional context: my workaround has been to listen for keyup events in Vue:
repo https://github.com/divensky/quasar-inputs, online demo: https://divensky.github.io/quasar-inputs/

However, this seems more like a hack. The right way to get the input is from an input event.

This does not seem to be specific to Vue: it is based on a JS value we get from a browser.

Comment 7

[Edgar Chen [:edgar]]

For the "internal" value, we follow the spec, same as other browsers.
For the "UX/UI", that is basically bug 1398528. Safari behave the same as us. Chrome has some character-blocking restrictions, but still allow user type some invalid value, see bug 1398528 comment #36.