NaN in color animation (Firefox 3)

Added visual tests

• http://jquery-ui.googlecode.com/svn/trunk/tests/visual/animate/animate_backgroundColor_hex.html
• http://jquery-ui.googlecode.com/svn/trunk/tests/visual/animate/animate_backgroundColor_rgb.html
• http://jquery-ui.googlecode.com/svn/trunk/tests/visual/animate/animate_color_hex.html
• http://jquery-ui.googlecode.com/svn/trunk/tests/visual/animate/animate_color_rgb.html

in r2306

Unable to reproduce using above tests. You may want to debug the value of 'newColor' as the error message suggests in may not be formatted correctly. Or if you can reproduce this, please attach a test page. Thanks.

I had the same problem, and I tracked it down to this initialisation code:

    if ( fx.state == 0 ) {
        fx.start = getColor( fx.elem, attr );
        fx.end = getRGB( fx.end );
    }

The problem is that the initialisation code doesn't always run because fx.state isn't always zero on the first call -- in one test, I found it was equal to 0.005. Replacing the if statement with "if ( fx.start.constructor != Array)" fixed the problem for me.

I don't have a test case that I can share, but it appears to be related to performance so I'd suggest testing it by running a very large number of concurrent animations on a slow computer.

Change:

if (fx.state == 0)

To:

if (fx.state == 0 || fx.start.constructor != Array || fx.end.constructor != Array)

Sometimes when this code is executed. fx.State is not 0, but fx.start and fx.end haven't been initialized as RGB arrays. In the updated code, we initialize the fx.start and fx.end arrays if they haven't been initialized.

That seems to have fixed it, but it's hard to be sure on an intermittent problem.

How fix this bug in repository?

Thanks defenestrator and aesnn for pointing us in the right direction.

There is a fairly easy way to reproduce this bug. This is a race condition in

jQuery.fx.custom

. You simply have to delay a little bit the first step so that

fx.state

is not 0.

When

jQuery.fx.step

is called for the first time, the current time (stored in variable

t

) can only be equals OR greater than

this.startTime

. Most of the time they are equals since they are only separated by a few instructions (in

jQuery.fx.custom

and then

fx.state

is 0. If the execution is slow enough (a one millisecond delay is enough, e.g. a log, a busy loop, ..), they will not be equals and then thw first state is not zero, resulting in this bug.

The issue is not in jQuery i guess, since i can't find anywhere where it is specified that state must be equal to 0 on the first step. This is a little bit disapointing to see that this bug has not been fixed since 3 months and has been closed without further investigation...

Fixed in r3269.