Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#4251 closed bug (fixed)

NaN in color animation (Firefox 3)

Reported by: lunchtimemama Owned by:
Priority: major Milestone: 1.8
Component: ui.effects.core Version: 1.6rc6
Keywords: Cc: [email protected]
Blocked by: Blocking:


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


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.

Change History (8)

comment:2 Changed 14 years ago by rdworth

Resolution: worksforme
Status: newclosed

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.

comment:3 Changed 14 years ago by 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.

comment:4 in reply to:  description Changed 14 years ago by aesnn


if (fx.state == 0)


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.

comment:5 Changed 14 years ago by aesnn

How fix this bug in repository?

comment:6 Changed 14 years ago by 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...

comment:7 Changed 14 years ago by rdworth

Resolution: worksforme
Status: closedreopened

comment:10 Changed 14 years ago by Scott González

Milestone: TBD1.8
Resolution: fixed
Status: reopenedclosed

Fixed in r3269.

Note: See TracTickets for help on using tickets.