Bug 154533

Summary: number-toLocaleString.js test fails on ARM Linux buildbots
Product: WebKit Reporter: Csaba Osztrogonác <ossy>
Component: JavaScriptCoreAssignee: Andy VanWagoner <andy>
Status: RESOLVED FIXED    
Severity: Normal CC: andy, commit-queue, darin, ews-watchlist, keith_miller, sukolsak, ysuzuki
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 147605    
Attachments:
Description Flags
Patch
none
Archive of layout-test-results from ews200 for win-future none

Csaba Osztrogonác
Reported 2016-02-22 05:08:58 PST
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.
Attachments
Patch (19.54 KB, patch)
2018-07-27 13:15 PDT, Andy VanWagoner
no flags
Archive of layout-test-results from ews200 for win-future (12.96 MB, application/zip)
2018-07-27 19:05 PDT, EWS Watchlist
no flags
Sukolsak Sakshuwong
Comment 1 2016-02-22 08:53:24 PST
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
Comment 2 2018-07-27 10:55:43 PDT
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
Comment 3 2018-07-27 13:15:21 PDT
EWS Watchlist
Comment 4 2018-07-27 19:04:55 PDT
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
Comment 5 2018-07-27 19:05:06 PDT
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 6 2018-07-27 23:42:26 PDT
Comment on attachment 345945 [details] Patch r=me
Darin Adler
Comment 7 2018-07-28 13:38:39 PDT
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
Comment 8 2018-07-28 16:16:08 PDT
(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 9 2018-08-01 13:53:54 PDT
Comment on attachment 345945 [details] Patch Test failure seems unrelated.
WebKit Commit Bot
Comment 10 2018-08-01 14:13:18 PDT
Comment on attachment 345945 [details] Patch Clearing flags on attachment: 345945 Committed r234473: <https://trac.webkit.org/changeset/234473>
WebKit Commit Bot
Comment 11 2018-08-01 14:13:20 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 12 2018-08-01 20:30:36 PDT
Note You need to log in before you can comment on or make changes to this bug.