1164402 - 16+ digit strings typed into <input type=number> by a user can't reliably be obtained via input.value

Status: RESOLVED WORKSFORME

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

Description

[garri.hovhannisyan]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

Steps to reproduce:

In my input type number was specified as max value 19 digit number.

But when I enter value which has 18 digits (for instance 555555555555555555) it will on run-time convert specified number to some strange one (55.5555555555556).

Please check my case here: https://jsfiddle.net/zb4ft1qq/79/


Actual results:

For big max values it work not properly, but for small ones it looks correct.


Expected results:

It is expected that entered value should not changed, truncated or rounded when it exceeds max value.

Comment 1

[garri.hovhannisyan]

Attachment: bug in mozilla.png

Comment 2

[Boris Zbarsky [:bzbarsky]]

The problem you're running into is that at some point object.value switches to scientific notation.  In particular, the value "555555555555555555" is ending up as "5.55555555555556e+17" when you get object.value, which is 21 characters long.

In general, nothing in the spec precludes the value being returned in scientific notation as far as I can tell.  As long as it's actually used as a number, there should not be a problem; the linked-to code is not using it as a number (it's comparing it string length to the string length of the max value instead).

Comment 3

[Jonathan Watt [:jwatt]]

(In reply to Not doing reviews right now from comment #2)
> The problem you're running into is that at some point object.value switches
> to scientific notation.  In particular, the value "555555555555555555" is
> ending up as "5.55555555555556e+17" when you get object.value, which is 21
> characters long.

Then your script truncates off the "e+17" (just to be clear).

Comment 4

[Jonathan Watt [:jwatt]]

It's also worth noting that Chrome converts the number to exponent notation as soon as you click on the decrement button.

I think the thing we're doing here that is different to Chrome is that we're sanitizing the value (not just the internal representation) after it's entered. If we avoided doing that then script examining the 'value' property wouldn't see the value change (and neither would the value displayed to the user).

Comment 5

[Boris Zbarsky [:bzbarsky]]

Per spec, reading .value is supposed to perform whatever sanitization is appropriate for the input type, for what it's worth.

Comment 6

[garri.hovhannisyan]

Thanks Guys for detailed explanation. 

This script works fine for other mainstream browsers (IE, Chrome, Netscape). Looks like they don't doing this sanitization.

How can I handle max value restriction in case of this Mozilla sanitization behavior ?

Thanks in Advance.

Comment 7

[garri.hovhannisyan]

Actually, how to convert/get entered value in standard form notation in javascript, instead of scientific  notation ?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Handle in what sense?  The browser will do that validation itself, on actual numeric values, not strings...  What are you trying to do in addition to what the browser would do anyway and why?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> how to convert/get entered value in standard form notation in javascript

It's not clear to me that there is a way to do that right now that's built into the browser.

Comment 10

[garri.hovhannisyan]

I'm using input type number for credit card number field, and should in case of master card restrict length of max allowed symbols to be entered in this field to 19.

On run-time I should not allow enter more than allowed 19 digit integer. In all other browsers my script works find except Mozilla and I'm slicing in this script entered number from 0 digit to max number digit length.

But only for Mozilla object.Value is returning scientific notation instead of normal one, as result I'm slicing/cutting number in scientific notation then logic is not work properly.

So, can you please suggest how can I overcome or make some workaround for Mozilla to do what is intended in script mentioned above.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> I'm using input type number for credit card number field

That seems like a misuse of input type number, because credit card numbers have various weird features like possible leading 0 that make them strings, not actual numbers, no?  Not only that, but the validation number inputs is wrong for credit card numbers, the increment/decrement functionality number inputs have is pointless for credit card numbers...

You should really be using a text input here, not a number input.

Comment 12

[garri.hovhannisyan]

I have separate validations for credit card number.

Initially, that field was implemented like input type text, but the issue was that, in tablets the by default was showed character keyboard, that's why decision was made to make input type number to also force mobile devices use numeric keyboard. So this the long story behind why we decide to switch to use number type field.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Ah.  There are proposals for being able to indicate the keyboard you want without changing the other behavior, but I'm not sure what the implementation state of those is yet...

Comment 14

[garri.hovhannisyan]

What I know, in html 5.1 was introduced new property inputmode="numeric".
What I don't know when browser will start support HTML 5.1 :)

Comment 15

[Boris Zbarsky [:bzbarsky]]

Right, that's the one I was thinking of.  Looks like no one really implements it yet.  :(

Comment 16

[garri.hovhannisyan]

Hm, is it right, that Mozilla support inputmode feature ? 
Look, what I found https://bugzilla.mozilla.org/show_bug.cgi?id=746142

Comment 17

[Boris Zbarsky [:bzbarsky]]

We have support in the code, but it's not turned on in release builds yet.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I believe type=number is fairly explicitly for inputting numeric values. And explicitly not for inputting things like credit card numbers, postal codes and codes.

I'd definitely like to see us implement inputmode=numeric. Though a lot of the other input modes I'm not so interested in.

Comment 19

[garri.hovhannisyan]

I'm not sure we will change back to input type text or not, it not only dependent to me.
So, what workaround can you please suggest there to solve that notation issue ?

Should be some solution to convert in javascript scientific to standard notation.

Comment 20

[Boris Zbarsky [:bzbarsky]]

You can parseFloat the number and then toPrecision it... however note that you've already lost accuracy by that point because the mantissa for the floating-point representations can't represent as many decimal digits as you're trying to represent here.

Comment 21

[Jonathan Watt [:jwatt]]

(In reply to Boris Zbarsky [:bz] from comment #20)
> You can parseFloat the number and then toPrecision it... however note that
> you've already lost accuracy by that point because the mantissa for the
> floating-point representations can't represent as many decimal digits as
> you're trying to represent here.

Indeed, any card number typed in by a user that is "greater" than https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER is likely to change during conversion to the double precision representation.

In fact right now there's actually no way to reliably get the string of digits as typed in by the user due to the way that we implement localization support. We pass the string typed in by the user through to input.value via nsNumberControlFrame::GetValueOfAnonTextControl, and that checks whether the input string can be passed through unmodified by comparing the value as parsed by ICUUtils::ParseNumber to the value as parsed by HTMLInputElement::StringToDecimal. This is to prevent strings such as "12.345" when lang=de being incorrectly passed through as 12.345 instead of 12345, for example. If the two parsed numbers are different then the GetValueOfAnonTextControl code assumes that we have hit just such a scenario and that we need to serialize the result from ICUUtils::ParseNumber and pass that through to set as input.value, in which case we (usually necessarily) lose the original formatting of the number as typed by the user. Unfortunately this code can end up triggering for 16 digit numbers, either because large integers with 15 or so significant digits cause problems for ICUUtils::ParseNumber, or because the lack of ability for double to represent numbers greater than MAX_SAFE_INTEGER and different rounding under ICUUtils::ParseNumber vs HTMLInputElement::StringToDecimal.

So in short there is no reliable workaround for Firefox.

Comment 22

[Jonathan Watt [:jwatt]]

I'm currently undecided on whether I should closes this as invalid, mark it as a duplicate of bug 1005603, or whether there might we some way to "fix" this to work at least to the extent that things "work" in Chrome/IE without fixing bug 1005603.

Note that I opened bug 1205133 to ship inputmode=numeric which would be a better way to solve your use case, Garri. Of course you'd then have the issue of having to provide different input types for Firefox vs. other browsers until they too implement inputmode=numeric.

Comment 23

[garri.hovhannisyan]

Hi Jonathan, 

In my opinion the best is when browsers behave consistently, so it would be nice fix this issue to work exactly how other mainstream browsers do with input type=numeric.

Thanks.

Comment 24

[Zach Leatherman]

I think this issue can be closed (or modified).

Attempting to reproduce the original comment in Firefox 47 seems to operate as expected for `value`.

Typing 555555555555555555 into the number field on http://output.jsbin.com/kovefemawu gives back:

* Rendered: 555555555555555555
* .value: 555555555555555555
* .valueAsNumber is incorrect though: 555555555555555600 and should probably return NaN instead (that’s how IE does it in version 11)

Comment 25

[vee w]

More example:
https://codepen.io/blacklightdesign/pen/OVPOWe

Enter number 12345678901.12345 and click on submit. It will be alert 12345678901.1234.
The last number (5) was round down.
This will be messed if the input number is scientific or architecture or financial calculation.

Chrome working on this correctly.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Enter number 12345678901.12345 and click on submit. It will be alert 12345678901.1234.

The fix for bug 981248 seems to fix this specific testcase. I'm not sure whether it fixes the original bug.