1005603 - When possible, <input type=number> should preserve the formatting of the 'value' attribute or any string assigned to input.value

Status: RESOLVED DUPLICATE of bug 981248

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

Description

[Alhadis]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140421221237

Steps to reproduce:

It's currently impossible to force leading zeroes in numeric-type input elements, so I had a script that manually set the values with leading zeroes (which was important because I was writing a lightweight stopwatch webapp that was geared toward mobile users... ergo, I wanted the device's OS to bring up the numeric keyboard when a user tapped a time component to edit its value manually):

For those interested, this is the script I was using: http://pastebin.com/Gxd6hHAH

Now, this was working perfectly fine in WebKit/Chromium, which would maintain leading zeroes in the input's value (as it wouldn't alter the value being set unless it didn't compute to a valid number: e.g., input.value = "003" would work, but not input.value = "wfsdgsdg").


Actual results:

When I tested this in FF29, the results were a colossal failure. Setting an input's value to "003" would display "3" in the input window, despite storing the value internally as "003". Leading zeroes are stripped from the element's initial value as well (that is, an HTML attribute of 'value="03"' would simply be reduced to "3", despite the element's internal value still being a string of "03". The only way that leading zeroes can even be inserted into a numeric input's value is if the user physically types it in themselves.

Test case here:
http://codepen.io/Alhadis/full/jKBmc


Expected results:

"03" evaluates to a valid floating-point number, so there's no reason to alter the literal string value at all. Furthermore, even if the user agent DOES see the need to strip leading zeroes when sanitising a value (which is stupid for so many reasons), it should at LEAST update the element's internal value to reflect this.

Comment 1

[Boris Zbarsky [:bzbarsky]]

John, can you explain what the use case is for a number input that has leading zeroes?  That's not how numbers are commonly written, and the spec explicitly doesn't support that behavior last I checked.

Comment 2

[Alhadis]

Boris: As I stated in the OP, a common use for keeping leading zeroes prepended to number inputs would be timers, and fields for setting days of the month (and before you bring up the "date" input type, I should mention that this does nothing if we need users to be able to set intermediate dates: e.g., YYYY-MM-DD, YYYY-MM or simply YYYY: using the same combination of fields).

In either case, common usage scenarios are moot here: the issue is that the displayed value is actually *not* reflecting the stored (and already sanitised) numeric value.

As far as the spec supporting this behaviour, it's actually not forbidden in the spec:
• http://www.w3.org/TR/html5/forms.html#number-state-(type=number)
• http://www.w3.org/TR/html5/infrastructure.html#valid-floating-point-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."

"0003" computes to a valid floating point number. Firefox internally recognises the input as a valid floating point number. It's just refusing to display it.

Comment 3

[John Radke]

(In reply to Boris Zbarsky [:bz] from comment #1)
> John, can you explain what the use case is for a number input that has
> leading zeroes?  That's not how numbers are commonly written, and the spec
> explicitly doesn't support that behavior last I checked.

The case I have is entering a time - hours and minutes as two number inputs. Hours doesn't strictly *need* the leading zero (though it'd be nice), but minutes absolutely does. "8:5" is not a valid representation of "five minutes after eight".

Comment 4

[Jonathan Watt [:jwatt]]

There seem to be two separate levels of sanitization (in a lose sense, not the spec defined sense) here. First there's the question of whether or not the internal value is sanitized, and second - if it is not - whether the displayed value is sanitized.

If we're not sanitizing the internal value, then I'd be happy for us to change so that we don't sanitize the displayed value either. That said, my reading of the spec is that we shouldn't even allow assignment of "003" to input.value. It does seem like it's useful to be able to do so though, and both Chrome and IE support that, so maybe we should too and we should get the spec changed.

Comment 5

[jzhobes]

(In reply to Not doing reviews right now from comment #1)
> John, can you explain what the use case is for a number input that has
> leading zeroes?  That's not how numbers are commonly written, and the spec
> explicitly doesn't support that behavior last I checked.

I would think a completely valid use case for a number input with leading zeroes are zip codes. Northeast zip codes begin with zero.

Comment 6

[Boris Zbarsky [:bzbarsky]]

ZIP codes aren't numbers.  Typical US ones can be 5 digits, or 5 digits followed by a - and then 4 more digits.  And of course if you have to deal with non-US addresses postal codes are very much not numbers.

Comment 7

[Boris Zbarsky [:bzbarsky]]

And, importantly, for a zip code you don't want the typical number UI with increment/decrement buttons, possible insertion of commas at the thousands place, etc.  A zip code formatted as "60,615" would look pretty odd to the user, but is a perfectly reasonable way for a UA to display a _number_ input.

Comment 8

[Boris Zbarsky [:bzbarsky]]

(Note that I consider John's earlier use case of hours/minutes much more compelling; a number input does make a lot of sense there.)

Comment 11

[Jonathan Watt [:jwatt]]

The reason that we display "3" when input.value is set to "003" is because in nsNumberControlFrame::SetValueOfAnonTextControl under the stack:

  nsNumberControlFrame::SetValueOfAnonTextControl
  mozilla::dom::HTMLInputElement::SetValueInternal
  mozilla::dom::HTMLInputElement::SetValue

we try to localize the value before displaying it to the user. Unfortunately there's no good way to determine whether using the localized string representation needlessly discards formatting or not. For example, "003" and "3." could probably be left as is for display, but "0030000.5" should be converted to "30.000,5" or something similar for lang=de.

It's worth noting that Chrome does not seem to bother to try to localize the value displayed to the user when input.value is set. It just sets the displayed string to the string assigned to input.value. While avoiding the problem described in this bug, that means that their localization story sucks here.

It seems to me this is either-or. Either we localize, or we preserve.

Comment 13

[jzhobes]

Our primary reasoning for using input type="number" is to trigger the numeric keyboard on Android/iOS devices. We use the following template to ensure it works across both Android and iOS:
<input type="number" pattern="[0-9]*">
- pattern="[0-9]*" - triggers the correct numeric keypad in iOS
- input type="number" - triggers the correct numeric keypad in Android 4

As for the increment/decrement buttons, we hide them via CSS. I'm aware it's very well possible to just use the `userAgent` string, but we're looking to avoid relying on device detection.

As John also mentioned, this impacts date fields of the format YYYY-MM-DD as well.

Comment 14

[junk]

Another use case which we just ran into is CVV fields on credit card forms. Many have leading zeros. They're always numbers and we need the number field to trigger the num pad on mobile.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Again, if what you want is the input stuff then you want inputmode (which browsers should implement).

Comment 16

[junk]

(In reply to Boris Zbarsky [:bz] from comment #15)
> Again, if what you want is the input stuff then you want inputmode (which
> browsers should implement).

That's not all I want. I also only want numbers in that field. This is one of the cases where the intention of the W3C conflicts with reality and how people actually want to use the tools provided. 

So yes, I could use the other field properties to get to the same result, but as you stated, other browsers don't yet. Those other browsers also don't follow the spec to the letter, as it doesn't really make any real world sense either.

Comment 17

[Zach Leatherman]

I would also +1 this issue to remove sanitation from .value assignments.

Consider the following cross browser tests: https://github.com/scottjehl/Device-Bugs/issues/71#issuecomment-231221770

All other modern browsers don’t sanitize .value assignments. Even disregarding that, Firefox doesn’t sanitize user input on blur so at least .value assignment should match that behavior.

Comment 18

[Chandan Singh]

Hi,

I am facing a similar issue. The use case in my case is entering the bank account numbers.

Comment 19

[jbirdwell34]

We are using the leading zeros for minutes in a time picker. Other browsers leave the value along. Here it is stripped. It creates strange looking time fields.

Comment 20

[coues Lou]

I got hit by this one, while trying to add trailing zero.
Use case is financial data. Price are usually written with a fixed number of decimal but firefox refuse to display 3.10 or 3.00 and will display 3.1 and 3

Comment 21

[kybishop]

3 years out and Firefox is the only major browser that still sanitizes number inputs. Would love to see input behaviour standardized so things like hour and minute inputs no longer look so strange.

Comment 22

[Rob]

Another use case would be any situation where a trailing zero is a significant figure. For example, data from a scientific experiment where measurements were measured with a certain amount of precision. When Firefox removes trailing zeroes, it falsely indicates a lower precision.

Comment 24

[martin]

+1 - Reporting in on another use case here for confirmation codes that get texted to the user. Sometimes they have leading zeroes, but are always numeric. AFAIK, Firefox is the only browser we have issues with.

Comment 25

[alister]

+1 - We are using form inputs for Librarians to add LC Classification/Dewey subclass ranges (e.g. 000.00 - 001.9999).  As mentioned above, Firefox is the only browser (to my knowledge) that sanitizes the input .val thereby removing important leading and trailing zero's from the form.

Comment 26

[Jonathan Watt [:jwatt]]

Attachment: Bug 1005603. Make <input type=number> preserve the formatting of the 'value' attribute or string assigned to input.value. r=mats

Comment 27

[Mats Palmgren (inactive)]

Please also file a HTML spec issue to update it to what UAs actually implement.

Comment 28

[Scott Cox]

Is there any news on this? Been ready to land since November 23 2018 :)

Comment 29

[Jonathan Watt [:jwatt]]

Comment on attachment 9027069 [details]
Bug 1005603. Make <input type=number> preserve the formatting of the 'value' attribute or string assigned to input.value. r=mats

This patch doesn't work correctly; it's not so simple after all. I'm close to having a replacement though.

Comment 30

[Jonathan Watt [:jwatt]]

Didn't mean to clear the NI.

Comment 31

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 32

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 33

[Govind]

Any update on this please. I have issue while entering account numbers and DOB

Comment 34

[Mike Taylor [:miketaylr]]

Note that the Vodaphone UK site depends on the expected behavior of this bug (Bug 1586870).

Hsin-yi, we should talk about this one in webcompat triage.

Comment 35

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

(In reply to Mike Taylor [:miketaylr] (slow to respond Oct 8 - Oct 13) from comment #34)

Note that the Vodaphone UK site depends on the expected behavior of this bug (Bug 1586870).

Hsin-yi, we should talk about this one in webcompat triage.

Thanks for the heads up! Reading through the old history. :)

Comment 36

[Mike Taylor [:miketaylr]]

Attachment: simple test case to compare across browsers

Comment 37

[Emilio Cobos Álvarez (:emilio)]

I think this is fixed by bug 981248: We still format the value for display, but reading back .value gets the raw string.

I think that should fix the issues that the compat team has seen. Mike, can you or anyone on your team confirm?

Comment 38

[Mike Taylor [:miketaylr]]

Yep! I just confirmed we get expected behavior in Nightly 74 (vs 73). Thank you!