Opened 8 years ago

Closed 8 years ago

Last modified 7 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: lunchtimemama@…
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 8 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 8 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 8 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 8 years ago by aesnn

How fix this bug in repository?

comment:6 Changed 8 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 8 years ago by rdworth

Resolution: worksforme
Status: closedreopened

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

Milestone: TBD1.8
Resolution: fixed
Status: reopenedclosed

Fixed in r3269.

Note: See TracTickets for help on using tickets.