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");
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.
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.
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. "
...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.)
Reassigning to webkit-unassigned, to make sure more people see this.
This is an enhancement request, as i agree with #c4, attaching testcase in a sec.
Created attachment 6512 [details] Testcase
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)
Created attachment 15258 [details] Test case
(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
<rdar://problem/5316243>
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 ***