Closed Bug 1134388 Opened 10 years ago Closed 1 year ago

Colon in JavaScipt toFixed() result

Categories

(Core :: JavaScript Engine, defect)

35 Branch
x86_64
Windows 7
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: bugzilla, Unassigned)

Details

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.
Component: Untriaged → JavaScript Engine
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?
Flags: needinfo?(bugzilla)
Till: 
I'm using a standalone computer where I write JavaScript/PHP/MySQL code for internal use. The NaN error led me to find this mysterious colon.
I ran the same suite of code on IE at the same time and the error did not arise.
It looked almost as if Fx was saying "there are too many 9's here, I'll just put a colon".

If I run your Developer Edition, can I be certain it will leave my normal Fx completely unchanged? I use it for work so don't have the time to experiment with clean profiles.
Ian
Flags: needinfo?(bugzilla)
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 Ian from comment #6)
> Till: 
> I'm using a standalone computer where I write JavaScript/PHP/MySQL code for
> internal use. The NaN error led me to find this mysterious colon.
> I ran the same suite of code on IE at the same time and the error did not
> arise.

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.

> It looked almost as if Fx was saying "there are too many 9's here, I'll just
> put a colon".

That is what it looks like indeed, yes. Looking at the implementation of toFixed, I can't find any trace of something that might cause this, however.
> 
> If I run your Developer Edition, can I be certain it will leave my normal Fx
> completely unchanged? I use it for work so don't have the time to experiment
> with clean profiles.
> Ian

Yes, that's why I recommended the Developer Edition. It creates a completely separate profile so you can even have it open at the same time as the normal version. What Waldo says in comment 7 also works, though, so you can do that with your normal Firefox, too.
(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>)?
Flags: needinfo?(bugzilla)
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).
Flags: needinfo?(bugzilla)
Severity: normal → S3
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.