Bug 249231
Summary: | REGRESSION (Safari 15.x): Intl.NumberFormat producing different results when compared to Chrome/FF | ||
---|---|---|---|
Product: | WebKit | Reporter: | Pedro <cunha.pedro.m> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | karlcow, mmaxfield, webkit-bug-importer, ysuzuki |
Priority: | P2 | Keywords: | BrowserCompat, InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Pedro
When using Intl.NumberFormat in combination with formatToParts there are inconsistencies with the Chrome/Firefox implementation. This was working fine in v15 of Safari but has since broken somewhere between 15.3 - 15.6.1, and continues to be broken in the latest version 16.1. Inconsistencies are detailed below:
1- When configuring the number format options like this:
{
minimumFractionDigits: 0,
maximumFractionDigits: 20,
useGrouping: true,
notation: 'compact',
compactDisplay: 'short',
}
Safari ignores the minimumFractionDigits and always rounds up or down depending on the decimal.
2- When formatting a number above 1000 Safari drops any additional fractions (unlike Chrome and FF). For example if the number is 1100, it should format to 1.1K in the compact display notation. Instead Safari drops the fraction part completely and simply formats it as 1K. Things get even stranger when formatting into the millions where Safari turns this: 1234567 into 1.2M, which is correct and consistent with other browsers. It could be that something is wrong in the handling when numbers are in the thousands.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/103490073>
Yusuke Suzuki
Thanks for your report! I think this is fixed in bug 246646.
Please check with the latest Safari Technology Preview.
*** This bug has been marked as a duplicate of bug 246646 ***