1027780 - keypress fails in number field

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[Miguel Angel Velazco]

Attachment: Captura de pantalla 2014-06-19 a la(s) 14.16.29.png

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

Steps to reproduce:

I've generated a keypress listener in order to validate numeric fields, search for a dot (.) in the value string with indexOf() , at the moment when you write very fast in the browser, this starts to fail.

You can check it with this fiddle http://jsfiddle.net/kN58a/


Actual results:

It's possible to write additional dots...


Expected results:

Detect with indexOf that the string has a dot.

Comment 1

[Nickolay_Ponomarev]

Thanks for the report!

I can't reproduce it with the most recent nightly build on OS X. Can you reproduce at will? What specific steps do I have to take?

It's not really clear what's the problem in the browser you're hinting at -- to make it clearer the description ought to be in terms of what events you see in what order and what values you get from the browser, possibly in a form of console.log output.

Also, there are a few gotchas with attempting to validate type=number with JS:
1) the input's value you get in the keypress handler is _before_ the keypress: http://stackoverflow.com/a/8795323/1026
2) The <input type=number>'s value will only return a number, or empty string for invalid numbers: http://stackoverflow.com/q/18677323/1026

Perhaps you could get more help at http://stackoverflow.com/ for this type of problem?

Comment 2

[Miguel Angel Velazco]

I've just uploaded a descriptive video to https://www.youtube.com/watch?v=NtniuJQAE_w . Sorry for the comment there are four additional dots
This issue doesn't occurs at Google Chrome.

Comment 3

[Nickolay_Ponomarev]

Thanks, but I still can't reproduce. I'm wondering if non-english keyboard or browser localization is necessary to reproduce...

Anyway, please figure out what's happening in your code -- what input from the browser makes it behave this way -- what events in what order, and what you get from the textbox's `value` in each event.

Comment 4

[Miguel Angel Velazco]

I've forked this fiddle in order to add some extra info and will attach a PDF file of the fiddle page
also some info about the computer I'm using, and a new video of this new fiddle

Fiddle: http://jsfiddle.net/wLo8ab78/1/

Comment 5

[Miguel Angel Velazco]

Attachment: Captura de pantalla 2014-10-06 a la(s) 16.53.22.png

Computer info #1

Comment 6

[Miguel Angel Velazco]

Attachment: Captura de pantalla 2014-10-06 a la(s) 16.52.50.png

Computer Info #2

Comment 7

[Miguel Angel Velazco]

Attachment: fiddle.pdf

Page Print.

Comment 8

[Miguel Angel Velazco]

The new video link is:
 http://youtu.be/mhKsecKbvOU.

Comment 9

[Miguel Angel Velazco]

I'd like to add that the error is independent of the keyboard, and the event is previous to the drawing in the input.

Comment 10

[Nickolay_Ponomarev]

Oh, now I have a guess. It seems that in your environment '.' is a thousands separator.

So the issue has nothing to do with typing fast, just with entering "111.111.111.111". It gets interpreted as the number "111111111111", as you can see in the debug output. bug 344616 has some discussion about this, but I didn't have time to read it through.

I see the same behavior if I use ',' instead of a '.', since comma is the thousands separator on my system.

Seems like the browser's working as expected... Do you agree?

Comment 11

[Miguel Angel Velazco]

the dot is the separator between points and decimals, and the script is made for allow only one dot. In the other browsers makes it very well.

I don't know why the browser detects it as a thousands separator.

Comment 12

[Miguel Angel Velazco]

Sorry, I meant that the dot is the separator between units and decimals.

Comment 13

[Nickolay_Ponomarev]

From
http://hg.mozilla.org/mozilla-central/annotate/9ee9e193fc48/layout/forms/nsNumberControlFrame.cpp#l736
http://hg.mozilla.org/mozilla-central/annotate/9ee9e193fc48/intl/unicharutil/util/ICUUtils.cpp#l44

I see the we try the following:
    48    // Try the language specified by a 'lang'/'xml:lang' attribute on mContent
    60    // Else try the language specified by any Content-Language HTTP header or
..otherwise use the browser's locale.

See also bug 844744, where this was implemented.

So with <input type=number lang=en> you shouldn't see this behavior.

I don't see why this should be changed. What are other browsers' behavior and why is it better?

Comment 14

[Nickolay_Ponomarev]

Again, thanks for the report! I learned a lot while investigating this and hope you did too.

I updated https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#Localization and https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement (the entry for `value`) with our findings.

Comment 15

[Miguel Angel Velazco]

It Works!!!!
Thanks a lot!!!
You really rocks!!

Only that, as far I know I have a format "es-HN" that means spanish from Honduras (I don't know why, I'm from Mexico and I've upgraded it automatically) and in Honduras keep the same numeric/currency format as US and Mexico.

I don't really know how good or bad would be to set the language for the browser language from the system locale settings from the computer (at least it should be useful ask or obtain the language and country from system or user). Of this things the normal user doesn't mind (and I think they souldn't).

It would be great to check the Language number formats in all languages/countries because, in theory I never should see this error because the number/currency format is totally compatible with the behavior that I wanted to obtain from this code.

Sorry for the english, is not my forte.