Closed Bug 1347869 Opened 7 years ago Closed 7 years ago

Function parseInt() doesn't work correctly with certain whitespaces.

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
52 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox52 --- affected
firefox53 --- affected
firefox54 --- affected
firefox55 --- affected

People

(Reporter: thomas.josseau.acc, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.88 Safari/537.36 Vivaldi/1.7.735.46

Steps to reproduce:

The official es5-shim (https://github.com/es5/es5.github.io) tests if parseInt() reproduces its default behavior with whitespace characters. If the test fails, the global function is rewritten - and the test actually fails only on Firefox, since version 52.

Here is a sample of wrong parsing :
parseInt('\x09\x0A\x0B\x0C\x0D\x20\xA0\u1680\u180E\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200A\u202F\u205F\u3000\u2028\u2029\uFEFF08');


Actual results:

The actual result is NaN.


Expected results:

The result should be 8 (correct result in Firefox with version below 52).
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d6a0b28b04e4b35494d15155f79e43cdc5244835&tochange=1a2b9edaff2e1addbded9de836a56c9924b6254a

André Bargull — Bug 1230490 - Part 2: Update JS Unicode support to 9.0.0. r=arai

André, is it expected after migration to Unicode 9?
Blocks: 1230490
Has Regression Range: --- → yes
Has STR: --- → yes
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox55: --- → affected
Component: Untriaged → JavaScript Engine
Flags: needinfo?(andrebargull)
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
This is expected.  Recent versions of Unicode changed U+180E MONGOLIAN VOWEL SEPARATOR so that it no longer is in the "Zs" "Space_Separator" category.  When |parseInt| sees \u180E in the string, it doesn't consider it as leading whitespace, it does consider it as a potential character to parse as number, and because it's not a number you get NaN as the result.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(andrebargull)
Resolution: --- → INVALID
Alright ! Thanks a lot for your answer. :)
You need to log in before you can comment on or make changes to this bug.