#7912 closed bug (fixed)

Opened January 06, 2011 03:04PM UTC

Closed February 17, 2011 05:16PM UTC

Last modified March 13, 2012 03:02PM UTC

$.fx.prototype.cur() is incompatible with cssHooks

Reported by:	anonymous	Owned by:
Priority:	high	Milestone:	1.5.1
Component:	effects	Version:	1.5
Keywords:		Cc:
Blocked by:		Blocking:

Description

To calculate the start value of a property being animated, $.fn.animate() uses $.fx.prototype.cur().

This function then tries to access the DOM property first and, should it fail, falls back to $.css(), which is cssHooks aware.

Unfortunately, the value returned by $.css() is invariably parsed as a Float, which breaks values for properties such as color, transform, gradient, etc.

var r = parseFloat( jQuery.css( this.elem, this.prop ) );
return r || 0;

Currently, cssHooks workaround this problem by re-calculating the start value on the very first step of the animation, see color.js and transform.js examples. Obviously, this solution is neither clean nor efficient.

Before returning the value, cur() could simply do the following:

var r = jQuery.css( this.elem, this.prop ),
  parsed = parseFloat(r);
return isNaN(parsed)? r : parsed;

But there's probably a good reason for it to currently return 0 when parseFloat fails. I need help finding this reason so that I can fix this bug.

Regards,

Louis-Rémi

Attachments (0)

Change History (9)

Changed January 06, 2011 06:05PM UTC by rwaldron comment:1

component:	unfiled → css
keywords:	→ needsreview
priority:	undecided → high

Thanks for taking the time to contribute to the jQuery project! Please provide a reduced jsFiddle test case to help us assess your ticket!

Additionally, test against the latest jQuery release and the jQuery 0 GIT version to ensure the issue still exists. Be Excellent to eachother!

Changed January 07, 2011 12:24PM UTC by anonymous comment:2

I've opened a pull request with the proposed code and a new unit test: https://github.com/jquery/jquery/pull/165

Changed January 09, 2011 09:54PM UTC by @T1B0 comment:3

i think with this little tweak that would be backward-compatible anyway :


var r = jQuery.css( this.elem, this.prop ),
  parsed = parseFloat(r) || 0;
return isNaN(parsed)? r : parsed;

Changed January 10, 2011 11:58AM UTC by lrbabe comment:4

Sorry, the code you propose and the current code would have the exact same effect, the returned value will be 0 for a complex property.

I'm wondering if we were defaulting to 0 because some browsers return 'undefined' or other weird values for properties that have not been set previously...

Changed January 10, 2011 05:45PM UTC by lrbabe comment:5

_comment0:	Of course, the 0 is here as a fallback for "" and "auto" values. \ Browsers never seem to return undefined... \ \ I've updated my pull request to take this fact into account. \ I'll add a unit test. \ \ I'm almost done with this bug. \ \ → 1294683690355929

Of course, the 0 is here as a fallback for "" and "auto" values.

Browsers never seem to return undefined...

I've updated my pull request to take this fact into account and I've also added unit tests.

Changed February 15, 2011 06:16PM UTC by dmethvin comment:6

component:	css → effects
keywords:	needsreview
milestone:	1.next → 1.5.1

Changed February 15, 2011 06:43PM UTC by snover comment:7

status:	new → open

Changed February 17, 2011 05:16PM UTC by louisremi comment:8

resolution:	→ fixed
status:	open → closed

Fixes #7912. Make sure .cur() only returns 0 as fallback value when it needs to ("", auto, undefined, null).

This change makes .cur() more .cssHooks friendly. .cur() now returns the unmodified value by

.css() if it isn't a number, number-alike or a value that needs a fallback to 0.

This way fx.start doesn't need to be recalculated for complex values.

Changeset: 85d9343271da85fc945bf37a604873eaf247a3a7

Changed February 17, 2011 06:39PM UTC by jitter comment:9

version:	git → 1.5

Side navigation