User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150122214805 Steps to reproduce: 0.09999999999999999.toFixed(2) (The actual code that revealed this was +((vamn / 60 / 24).toFixed(2)) where vamn is 144; this returned NaN). Actual results: "0.0:" - i.e. there is a rogue colon in the result Expected results: "0.1" as in IE11.
Expected result should say "0.10" as in IE11.
Product: Firefox → Core
I get "0.10" when I do "0.09999999999999999.toFixed(2)", in both Firefox 35 and in a current nightly. At least on Mac...
And just checked a 32-bit nightly build on Mac, same thing: "0.10".
Well, it's a week now and no one seems to have checked this on Windows. If confirmed, it seems quite a serious bug, meaning toFixed() will wrongly cause NaN in some cases. It's not just a case of some displayed result looking a bit odd. Code that reads the result of toFixed() may fail.
Just tested this in Windows 8.1, and I see the correct result. Ian, even though this isn't the same version of Windows, I think it's extremely unlikely that this is a problem I would see if I tested on Windows 7. Partly because the platform dependency for this isn't all that substantial (in fact, it's very small and shouldn't matter for which exact string is emitted), so the exact version shouldn't matter, and partly because you're right: this would be a pretty serious bug if every Windows 7 user experienced it. We're running extensive test suites on Windows seven which, among many, many other things, also test Number#toFixed. What that means is that it's quite likely that something about your system configuration is part of the problem. To investigate further, it'd help to check if this happens in a clean profile. I think the easiest way to do that is to download the Developer Edition, which uses an independent profile: https://www.mozilla.org/en-US/firefox/channel/#developer Also, how exactly are you testing this? In a test script in some html document, in the Scratchpad that's integrated into the developer tools, or in some other way altogether?
If you run it using the Run dialog like path\to\that\firefox.exe -no-remote -profile "C:\path\to\empty\directory" then yes, your existing profile will be left alone, and all modifications will occur only in that empty directory.
(In reply to Till Schneidereit [:till] from comment #8) > It would be great if you could check if the same thing occurs if you run > just the code from comment 0 in isolation. Either by creating an otherwise > empty html document, or by opening the console (ctrl-shift-k) and pasting it > there. In the console, with +((144 / 60 / 24).toFixed(2)) I get NaN! Almost bedtime here so it will be tomorrow before I can reply again.
(In reply to Ian from comment #9) > In the console, with +((144 / 60 / 24).toFixed(2)) > I get NaN! Hum, that's not good. It would be really great if you could test in a clean profile. > Almost bedtime here so it will be tomorrow before I can reply again. Yes, same here :) Thanks for the investigation so far, and sorry it took a while for us to follow up here.
This is in the console of a freshly downloaded Firefox Developer Edition, not Synced to my existing profile. 0.09999999999999999.toFixed(2); // "0.0:" 0.09999999999999999.toFixed(14); // "0.0:000000000000" 0.09999999999999999.toFixed(15); // "0.100000000000000" As you can see, the colon disappears with toFixed(15). Is there somewhere I can look at the source code? Sometimes a fresh eye spots things! Ian
http://mxr.mozilla.org/mozilla-central/source/js/src/jsnum.cpp#912 and follow the breadcrumbs from there. You get into dtoa code in fairly short order, tho, and that code is not super-scrutable, so I doubt it'll be too effective. Really, we want to catch this in a debugger somehow to see what's going wrong at a machine code level, and to see what source code could possibly be causing this. Frankly, I wonder if it isn't something like system-level malware or so. :-(
This is a fairly new machine and kept pretty clean, and I don't get the fault in IE. I'm no expert but I might want to have a good look at http://mxr.mozilla.org/mozilla-central/ident?i=js_dtostr E.g. what would you expect to see if numEnd left a gap when end-padding with zeros? Couldn't someone there just try it on Windows 7 Pro ?-) Ian
I tested out 0.09999999999999999.toFixed(14); // "0.0:000000000000" on a Win7 Pro machine -- 64-bit OS, 32-bit build (the only thing we're shipping to users right now). This was a build of rev eea6188b9b05, build ID 20150302030204. I get "0.10000000000000" as the result. Again, I think this is something peculiar to your machine, although what it is, I haven't the foggiest.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #14) > I tested out > 0.09999999999999999.toFixed(14); // "0.0:000000000000" Did you test with any other values apart from 14? I'm a bit disappointed no one is having a proper look at this.
Testing the latest Nightly on Windows 7 x64 w/SP1: 32-bit: 0.09999999999999999.toFixed(2); // "0.10" 0.09999999999999999.toFixed(14); // "0.10000000000000" 0.09999999999999999.toFixed(15); // "0.100000000000000" 64-bit: 0.09999999999999999.toFixed(2); // "0.10" 0.09999999999999999.toFixed(14); // "0.10000000000000" 0.09999999999999999.toFixed(15); // "0.100000000000000"
Ian, We really need to figure out a way to reproduce this, to get somewhere on it... This problem is appearing for you in a clean profile, right? Do you also see it in safe mode (see <https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode?redirectlocale=en-US&redirectslug=Safe+Mode#w_how-to-start-firefox-in-safe-mode>)?
Oh, and also possibly relevant, is the system locale set to anything interesting?
Firefox in safe mode: 0.09999999999999999.toFixed(14); "0.0:000000000000" 0.09999999999999999.toFixed(15); "0.100000000000000" Firefox Developer in safe mode is the same. The locale is English (United Kingdom).
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.