keypress fails in number field




4 years ago
4 years ago


(Reporter: Miguel Angel Velazco, Unassigned)


30 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)



(4 attachments)



4 years ago
Created attachment 8442985 [details]
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

Actual results:

It's possible to write additional dots...

Expected results:

Detect with indexOf that the string has a dot.


4 years ago
Flags: in-qa-testsuite+
Flags: a11y-review+
Priority: -- → P1
Hardware: x86 → x86_64

Comment 1

4 years ago
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:
2) The <input type=number>'s value will only return a number, or empty string for invalid numbers:

Perhaps you could get more help at for this type of problem?
Flags: needinfo?(velazcomtz.miguel)
Flags: in-qa-testsuite+
Flags: a11y-review+
Priority: P1 → --

Comment 2

4 years ago
I've just uploaded a descriptive video to . Sorry for the comment there are four additional dots
This issue doesn't occurs at Google Chrome.
Flags: needinfo?(velazcomtz.miguel)

Comment 3

4 years ago
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.
Flags: needinfo?(velazcomtz.miguel)

Comment 4

4 years ago
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

Flags: needinfo?(velazcomtz.miguel)

Comment 5

4 years ago
Created attachment 8500700 [details]
Captura de pantalla 2014-10-06 a la(s) 16.53.22.png

Computer info #1

Comment 6

4 years ago
Created attachment 8500701 [details]
Captura de pantalla 2014-10-06 a la(s) 16.52.50.png

Computer Info #2

Comment 7

4 years ago
Created attachment 8500702 [details]

Page Print.

Comment 8

4 years ago
The new video link is:

Comment 9

4 years ago
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

4 years ago
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 "". 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

4 years ago
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

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

Comment 13

4 years ago

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?
Last Resolved: 4 years ago
Resolution: --- → INVALID

Comment 14

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

I updated and (the entry for `value`) with our findings.

Comment 15

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.