Bug 154533 – number-toLocaleString.js test fails on ARM Linux buildbots

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Csaba Osztrogonác]

New test case was added by http://trac.webkit.org/changeset/196850 ,
but it fails on EFL ARM(v7) buildbots with this diff:
-PASS Infinity.toLocaleString() is "∞"
+FAIL Infinity.toLocaleString() should be ∞. Was INF.

[Sukolsak Sakshuwong]

This is likely the same issue as Bug 152448. It is because Intl uses POSIX locale.

    $ LANG=en_US.UTF-8 ./jsc -e "print(Infinity.toLocaleString())"
    ∞
    $ LANG=en_US_POSIX.UTF-8 ./jsc -e "print(Infinity.toLocaleString())"
    INF

The proposed patch in Bug 152448 should fix it.

[Andy VanWagoner]

This behavior looks correct, considering that the POSIX English locale uses "INF" instead of US English's "∞" symbol to represent infinity.

The test should be updated to specify a locale, instead of assuming the default locale's behavior.

[Andy VanWagoner]

Created attachment 345945 [details]
Patch

[EWS Watchlist]

Comment on attachment 345945 [details]
Patch

Attachment 345945 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/8679142

New failing tests:
http/tests/security/canvas-remote-read-remote-video-hls.html

[EWS Watchlist]

Created attachment 345985 [details]
Archive of layout-test-results from ews200 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews200  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Yusuke Suzuki]

Comment on attachment 345945 [details]
Patch

r=me

[Darin Adler]

Comment on attachment 345945 [details]
Patch

Great to make the main tests not sensitive to the default locale. Do we need some kind of default locale test? I worry if that’s untested.

[Andy VanWagoner]

(In reply to Darin Adler from comment #7)
> Comment on attachment 345945 [details]
> Patch
> 
> Great to make the main tests not sensitive to the default locale. Do we need
> some kind of default locale test? I worry if that’s untested.

That's what intl-default-locale.html is for. for the actual default, it only verifies that it is a canonical language tag string.

window.internals.setUserPreferredLanguages is then used to test at least the userPreferredLanguages() path inside defaultLocale().

We can add cases to this test if there is some way to set WebCore's defaultLanguage() and some way to set ICU's uloc_getDefault(). As is, I don't think those are exposed in JavaScript.

[Keith Miller]

Comment on attachment 345945 [details]
Patch

Test failure seems unrelated.

[WebKit Commit Bot]

Comment on attachment 345945 [details]
Patch

Clearing flags on attachment: 345945

Committed r234473: <https://trac.webkit.org/changeset/234473>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/42840413>