NaN in color animation (Firefox 3)

[lunchtimemama]

I have elements which change color when you click on them. The code essentially looks like this:

$(element).click(function(){
  $(this).stop().animate({color:newColor},"fast");
});

Every now and again, the color doesn't change. When I consult the Firefox error console, I see lots of these:

Warning: Expected number or percentage in rgb() but found 'NaN'. Error in parsing value for property 'color'. Declaration dropped.

I'm using FF 3.0.6 on Vista 32 SP1.

[rdworth]

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

[rdworth]

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.

[defenestrator]

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.

[aesnn]

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.

[aesnn]

How fix this bug in repository?

[dprunier]

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...

[Scott González]

Fixed in r3269.