1693727 - <input type="number"> allows to input text

Status: RESOLVED DUPLICATE of bug 1398528

(Core :: Layout: Form Controls, defect)

Description

[Stanislav]

Attachment: scr.bmp

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Actual results:

<input type="number"> allows to input text

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Jonathan Kew [:jfkthame]]

This behavior seems to match Safari: both browsers allow any text to be entered into the control (but will mark it as invalid if it can't be parsed as a number). Chrome, on the other hand, only allows digits to be entered. (Actually, not quite: it allows a single "e", so you can enter something like "1e6", and it allows a decimal point -- but not a decimal comma, at least in my English version.)

I don't think the Firefox (and Safari) behavior here of allowing any character to be typed, and marking the value as invalid when appropriate is "wrong", it's just a different approach to the UX.

(There are also various other differences in behavior between implementations of <input type=number>: e.g. Firefox allows the user to enter a number using Eastern-Arabic numerals (۱۲۳) or Devanagari numerals (१२३), etc., and interprets these correctly, whereas Chrome simply doesn't let them be typed at all.)

Comment 3

[Jonathan Kew [:jfkthame]]

:jwatt, I'm curious what you think about this -- should we consider changing the behavior to be more Chrome-like (blocking non-numeric input from being entered at all), or should we keep the current behavior?

One oddity about the Chrome approach is the treatment of pasted input. If I have a mix of numbers and non-numbers on the clipboard (e.g. a date like "Jan 19, 2021", or numbers within a textual context like "pp 15–20") and paste it into an <input type=number>, Chrome will simply strip the non-numeric characters and paste what's left as a single number ("192021" or "1520" in these examples), which probably isn't very helpful. Firefox, in contrast, will paste exactly what's on the clipboard; the input control will then be highlighted as invalid and it's up to the user to decide what to do with it. I tend to think that's a more useful approach.

Comment 6

[Jonathan Watt [:jwatt]]

(In reply to Jonathan Kew (:jfkthame) from comment #3)

:jwatt, I'm curious what you think about this -- should we consider changing the behavior to be more Chrome-like (blocking non-numeric input from being entered at all), or should we keep the current behavior?

My thoughts about that so far are over in bug 1398528.

One oddity about the Chrome approach is the treatment of pasted input. If I have a mix of numbers and non-numbers on the clipboard (e.g. a date like "Jan 19, 2021", or numbers within a textual context like "pp 15–20") and paste it into an <input type=number>, Chrome will simply strip the non-numeric characters and paste what's left as a single number ("192021" or "1520" in these examples), which probably isn't very helpful. Firefox, in contrast, will paste exactly what's on the clipboard; the input control will then be highlighted as invalid and it's up to the user to decide what to do with it. I tend to think that's a more useful approach.

I think it depends. If the control is obviously for numeric input then Chrome's behavior could be useful. At the very least Chrome helpfully will strip any surrounding white space from anything you copied and pasted, whereas Firefox will mark a number with a leading or trailing space as invalid, which would be confusing if the user doesn't notice. Anyway, let's have any further discussion in the bug this was duped to.