5258 2005-10-04 10:52:18 -0700 toFixed() doesn't handle enough cases 2007-12-28 15:16:27 -0800 1 1 1 Unclassified WebKit JavaScriptCore 420+ Other All RESOLVED DUPLICATE 16640 HasReduction, InRadar P2 Normal --- 1 staikos webkit-unassigned ian oldest_to_newest 21337 0 staikos 2005-10-04 10:52:18 -0700 Number.toFixed() doesn't handle any case besides 0..20 which is not what FireFox does. See the testcases below. I don't have a patch to fix all of this at this time. Here are some testcases: print(eval("Number(1234.567).toFixed(undefined)")); print("expected 1235"); print(eval("Number(1234.567).toFixed(0)")); print("expected 1235"); print(eval("Number(1234.567).toFixed(1)")); print("expected 1235.6"); print(eval("Number(1234.567).toFixed(2)")); print("expected 1235.57"); print(eval("Number(1234.567).toFixed(-1)")); print("expected 1230"); print(eval("Number(1234.567).toFixed(-4)")); print("expected 0"); print(eval("Number(1234.567).toFixed(-5)")); print("expected 0"); print(eval("Number(1234.567).toFixed(1/0)")); print("expected exception"); 27695 1 ricciadams 2006-01-03 20:02:36 -0800 Section 15.7.4.5 of ECMA-262 documents the correct behavior of toFixed(). Step 2 specifically states that a RangeError exception should be thrown for cases other than 0..20. Thus, I believe that JavaScriptCore's behavior for the last 7 test cases presented in the above comment is correct. However, step 1 states that toFixed(undefined) should be the same as toFixed(0). This does not appear to be the case in our implementation. 27696 2 ricciadams 2006-01-03 20:20:37 -0800 Oops. toFixed(undefined) was fixed in http://bugzilla.opendarwin.org/show_bug.cgi?id=6267 . I accidentally tested in latest-released Safari instead of ToT. 27733 3 maksim 2006-01-04 11:49:39 -0800 Both behavior are valid, actually. At the second of the section, you'll noticed: "An implementation is permitted to extend the behaviour of toFixed for values of fractionDigits less than 0 or greater than 20. In this case toFixed would not necessarily throw RangeError for such values. " 28690 4 gavin 2006-01-17 07:14:35 -0800 ...which means that this is less of a bug report, and more of a feature request. (To the extent that not matching some non-standard behavior of browser X is a feature mis-match and not a bug.) 32392 5 joost 2006-02-13 16:04:26 -0800 Reassigning to webkit-unassigned, to make sure more people see this. 32786 6 joost 2006-02-15 14:53:27 -0800 This is an enhancement request, as i agree with #c4, attaching testcase in a sec. 32787 7 6512 joost 2006-02-15 14:53:45 -0800 Created attachment 6512 Testcase 6171 8 rossacher 2007-06-26 13:08:41 -0700 toFixed as well as toPrecision do have failures which seem related to this issue. The following testcase demonstrates one of the very clear ones. <html> <head> <title>Test</title> <script type="text/javascript"> var zahl1=1.0; var zahl2=1.000000001; var zahl3=-0.0; var zahl4=-0.00001; alert("1.0=="+zahl1.toPrecision(6)+"=="+zahl2.toPrecision(6)); alert("0.0=="+zahl3.toFixed(3)+"=="+zahl4.toFixed(3)); </script> </head> <body> </body> </html> This issue was Bug 136734 in kde and is fixed meanwhile in kde(don't ask me how. I did not have a look at the code till now) 6166 9 15258 rossacher 2007-06-26 13:11:15 -0700 Created attachment 15258 Test case 5488 10 ddkilzer 2007-07-05 20:44:29 -0700 (In reply to comment #9) > Created an attachment (id=15258) [edit] > Test case This test case assert()'s running a local debug build of WebKit r24013 with Safari 3.0 (522.12) on Mac OS X 10.4.10 (8R218): /path/to/WebKit/JavaScriptCore/kjs/number_object.cpp:371: failed assertion `n < intPow10(p)' Abort trap 5468 11 ddkilzer 2007-07-05 20:46:34 -0700 <rdar://problem/5316243> 65498 12 eric 2007-12-28 15:16:27 -0800 The patches attached to bug 16640 make us pass these tests. I'm going to dup this to bug 16640 unless there are objections. *** This bug has been marked as a duplicate of 16640 *** 6512 2006-02-15 14:53:45 -0800 2006-02-15 14:53:45 -0800 Testcase test.html text/html 870 joost PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgpkb2N1bWVudC53cml0ZShldmFsKCJOdW1i ZXIoMTIzNC41NjcpLnRvRml4ZWQodW5kZWZpbmVkKSIpKyI8YnI+Iik7CmRvY3VtZW50LndyaXRl KCIgZXhwZWN0ZWQgMTIzNTxicj4iKTsgIApkb2N1bWVudC53cml0ZShldmFsKCJOdW1iZXIoMTIz NC41NjcpLnRvRml4ZWQoMCkiKSsiPGJyPiIpOyAgCmRvY3VtZW50LndyaXRlKCIgZXhwZWN0ZWQg MTIzNTxicj4iKTsgIApkb2N1bWVudC53cml0ZShldmFsKCJOdW1iZXIoMTIzNC41NjcpLnRvRml4 ZWQoMSkiKSsiPGJyPiIpOyAgCmRvY3VtZW50LndyaXRlKCIgZXhwZWN0ZWQgMTIzNS42PGJyPiIp OyAgCmRvY3VtZW50LndyaXRlKGV2YWwoIk51bWJlcigxMjM0LjU2NykudG9GaXhlZCgyKSIpKyI8 YnI+Iik7ICAKZG9jdW1lbnQud3JpdGUoIiBleHBlY3RlZCAxMjM1LjU3PGJyPiIpOyAgCmRvY3Vt ZW50LndyaXRlKGV2YWwoIk51bWJlcigxMjM0LjU2NykudG9GaXhlZCgtMSkiKSsiPGJyPiIpOyAg CmRvY3VtZW50LndyaXRlKCIgZXhwZWN0ZWQgMTIzMDxicj4iKTsgIApkb2N1bWVudC53cml0ZShl dmFsKCJOdW1iZXIoMTIzNC41NjcpLnRvRml4ZWQoLTQpIikrIjxicj4iKTsgIApkb2N1bWVudC53 cml0ZSgiIGV4cGVjdGVkIDA8YnI+Iik7ICAKZG9jdW1lbnQud3JpdGUoZXZhbCgiTnVtYmVyKDEy MzQuNTY3KS50b0ZpeGVkKC01KSIpKyI8YnI+Iik7ICAKZG9jdW1lbnQud3JpdGUoIiBleHBlY3Rl ZCAwPGJyPiIpOyAgCmRvY3VtZW50LndyaXRlKGV2YWwoIk51bWJlcigxMjM0LjU2NykudG9GaXhl ZCgxLzApIikrIjxicj4iKTsgIApkb2N1bWVudC53cml0ZSgiIGV4cGVjdGVkIGV4Y2VwdGlvbjxi cj4iKTsKPC9zY3JpcHQ+ 15258 2007-06-26 13:11:15 -0700 2007-06-26 13:11:15 -0700 Test case test1.html text/html 298 rossacher PGh0bWw+CjxoZWFkPgo8dGl0bGU+VGVzdDwvdGl0bGU+CjxzY3JpcHQgdHlwZT0idGV4dC9qYXZh c2NyaXB0Ij4KdmFyIHphaGwxPTEuMDsKdmFyIHphaGwyPTEuMDAwMDAwMDAxOwp2YXIgemFobDM9 LTAuMDsKdmFyIHphaGw0PS0wLjAwMDAxOwphbGVydCgiMS4wPT0iK3phaGwxLnRvUHJlY2lzaW9u KDYpKyI9PSIremFobDIudG9QcmVjaXNpb24oNikpOwphbGVydCgiMC4wPT0iK3phaGwzLnRvRml4 ZWQoMykrIj09Iit6YWhsNC50b0ZpeGVkKDMpKTsKPC9zY3JpcHQ+CjwvaGVhZD4KPGJvZHk+Cjwv Ym9keT4KPC9odG1sPg==