1541053 - <INPUT> value gets cleared on blur or "type" change.

Status: UNCONFIRMED

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

Description

[mfaust]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Steps to reproduce:

Create an element of <input type=number patter=[0-9 ]* inputtype=numeric>
Text is entered such as "1234 " with a space at the end.
Either blurring away from the field or changing the type to "text" (el.setAttribute('type','text')) clears the value from the field.

Actual results:

The value is cleared from the field.

Expected results:

The value should remain since it matches the pattern. Ideally Firefox should support the "inputmode" attribute so a numeric keyboard can be displayed while still allowing for non-numeric values to be entered (space or others). Allowing for switching of "input" and "inputmode" values should also be allowed so that the appropriate soft keyboard can be displayed on mobile devices. This is useful in various scenarios and is generally supported on non-Firefox browsers.

Comment 1

[Cameron McCormack (:heycam)]

Moving this to DOM since it's more about the behavior of the control than its layout.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Mirko is looking at related issues and may provide ideas of what's up here.

Bug 1205133 is tracking the work "Ship inputmode=numeric"

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia)]

Reproduction steps (the above contains typos, e.g., "inputtype" instead of "inputmode"):

1. Open data:text/html,<input type=number pattern="[0-9 ]*" inputmode="numeric">.
2. Enter "1234 " (blank at the end).
3. Use dev-tools to change the type to text:

x = document.querySelector("input");
x.setAttribute('type', 'text');

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia)]

@mfaust:

1. From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number#Pattern_validation: "<input type="number"> elements do not support use of the pattern attribute for making entered values conform to a specific regex pattern."
2. This also complies to the whatwg standard (https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):
   "The following content attributes must not be specified and do not apply to the element: [...] pattern, [...]".

That is, one shouldn't use the "pattern" attribute for <input type="number">.

However, the support of inputmode="numeric" would solve your use-case, I guess. Unfortunately, the different specifications (WHATWG, W3C) seem to disagree on the support of it.

Anne: do you maybe have an idea towards which direction the support of inputmode="numeric" is going?

Comment 5

[Anne (:annevk)]

There's multiple things here:

1. patter is not an attribute, but also, as Mirko pointed out, pattern doesn't apply here.
2. inputtype is not an attribute either and we don't support new inputmode values yet. Tracked by bug 1509527 (and elsewhere). (Also, W3C's HTML fork isn't relevant, so yes, inputmode is to be supported. (MDN is not the source for deciding what to implement.))
3. We mark "1234" in <input type=number> as invalid whereas Chrome does not. (I cannot reproduce the blur behavior, is that Windows only?) It appears there's a different "value sanitization algorithm" at play or perhaps in how the value is obtained. That's the interoperability problem this bug describes as far as I can tell.

To address 3:

1. We'll need more tests to know what Chrome does and maybe also what Safari does.
2. We should file a tracking issue against the HTML Standard as it probably needs clarifying changes.

I suspect what we do wrong is that we validate before we parse or our floating-point parser is incorrect. The parser would ignore the trailing space per the HTML Standard, As it's user input we could arguably use a different parser for UX reasons, but I'm not sure that's useful, especially when it comes to trailing whitespace.

(OP should probably not use <input type=number> for non-number input though. If you need a numeric keyboard, that's what inputmode=numeric is for.)

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia)]

(In reply to Anne (:annevk) from comment #5)

There's multiple things here:

1. patter is not an attribute, but also, as Mirko pointed out, pattern doesn't apply here.
2. inputtype is not an attribute either and we don't support new inputmode values yet. Tracked by bug 1509527 (and elsewhere). (Also, W3C's HTML fork isn't relevant, so yes, inputmode is to be supported. (MDN is not the source for deciding what to implement.))
3. We mark "1234" in <input type=number> as invalid whereas Chrome does not. (I cannot reproduce the blur behavior, is that Windows only?) It appears there's a different "value sanitization algorithm" at play or perhaps in how the value is obtained. That's the interoperability problem this bug describes as far as I can tell.

Chrome filters the blank when manually entering or pasting it, so it won't become part of "value". If one pastes for instance 123 123, the blank will be filtered out. Analogous for 1234. At least that's happening on Ubuntu 18.04. I guess the filtering happens already before any value sanitization. If value = "1234 " is set via JavaScript, Chrome also recognizes that as invalid and sets the value to the empty string.

To address 3:

1. We'll need more tests to know what Chrome does and maybe also what Safari does.
2. We should file a tracking issue against the HTML Standard as it probably needs clarifying changes.

I suspect what we do wrong is that we validate before we parse or our floating-point parser is incorrect. The parser would ignore the trailing space per the HTML Standard, As it's user input we could arguably use a different parser for UX reasons, but I'm not sure that's useful, especially when it comes to trailing whitespace.

(OP should probably not use <input type=number> for non-number input though. If you need a numeric keyboard, that's what inputmode=numeric is for.)

Comment 7

[Anne (:annevk)]

Ah, I confused Chrome with Safari, my bad. But yeah, I guess the question is whether we should have similar filtering or a more lacks parser for user input.