live test case

Resetting milestone to future.

I have seen similar buggy behavior with opacity and position on Chrome.

Both are reproduced here: http://jsfiddle.net/24cVh/3/

Position animation jumps to wrong position at the start and then animation is smooth to the right target position. Opacity jumps to 0 and then animates correctly to target value. Both animations should not jump, as they work in FF.

Position is buggy both in Windows and Linux, Opacity only in Linux version of Chrome 7.

I'm seeing a similar bug with jQuery 1.5.1 and Chrome 10.

animate position works on FireFox, but on Chrome, the start of the animation jumps back to the initial value from page load, rather than the current value.

This issue doesn't seem to be "nice in firefox" either - It appears that the start value of any % based animation is being calculated incorrectly.

It has something to do with the calculation based on non-px values... There is a precision error going on here.

if ( unit !== "px" ) {
	jQuery.style( this, p, (end || 1) + unit);
	start = ((end || 1) / e.cur()) * start;
	jQuery.style( this, p, start + unit);
}

If the value for "end" is closer to say 100% the accuracy of the "starting" point is much higher...

Compare the jumpiness of the first frame of the animation on these two fiddles: http://jsfiddle.net/GVFah/5/ (end point 1%) http://jsfiddle.net/GVFah/4/ (end point 100%) -- In the case of % values we might just want to always use "100%" for this original start point calculation?

I submitted a pull request at https://github.com/jquery/jquery/pull/808.

The position animation bug that aivo mentioned (comment 4) is actually #9505. (I can't see anything wrong with the opacity animation.)

gnarf, reviewing this ticket, noticed that there is a major regression for percentage based animations. Run this fiddle on edge, and compare the behavior to 1.7.2: http://jsfiddle.net/GVFah/4/

@mikesherov, it ''is'' possible for tween.cur() to return 0 in the starting value computation, and the current method will respond by setting start to Infinity. I advocate a fix generalizing the above pull request into iterative approximation; something like the following (but perhaps less obfuscated):

// We need to compute starting value
if ( unit !== "px" && start ) {
    // Iteratively approximate from a nonzero starting point
    // Prefer the current property; this process will be trivial if units match
    // Fallback to end or a simple constant
    start = parseFloat( jQuery.style( tween.elem, prop ) ) || end || 1;
    
    do {
        // If previous iteration zeroed out, double until we get *something*
        scale = scale || 0.5;
        
        // Adjust and apply
        start = start / scale;
        jQuery.style( tween.elem, prop, start + unit );
        
    // Update scale, tolerating zeroes from tween.cur()
    // Stop looping if scale is unchanged or we've hit the mark
    } while ( scale !== (scale = tween.cur() / target) && scale !== 1 );
}

http://jsfiddle.net/JjQ4e/

(Note that we can skip the block entirely when start === 0).

And as an aside, I love the new animation hook points; they made this a breeze.

richard, take this one home! You have the solution already.

Damn; I was really hoping you'd have something to offer on "perhaps less obfuscated"... that while condition is hairy as hell.

I suppose I can take a look. I was hastily reassigning it to you. I figured I can nitpick after you get the PR together :-P

The other question is, does this resolve the regression I pointed out?

It'll shake out with the unit tests, but I believe so. The code on master miscalculates non-px start from trying to set style information on an animation object instead of its element. A naive correction would still suffer from miscalculation when end is sufficiently small, catastrophically when it is small enough to make tween.cur() return 0. PR 808 handles the first issue and goes a long way to handling the second; I just took it that final step.

Actually, I'd really just like to see PR 808 updated with the generalized code and unit tests so @jeff_themovie gets the credit he deserves. I'll save this for now and come back to it if there's no activity within a few days.

I've updated the PR with Richard's test case and generalized solution. (Thanks Richard - awesome stuff!) Let me know if there's any other changes I should make.

I would think that the best way to calculate this would be to always assume "100" + unit when calculating the "unit value" -- it should give us enough granularity

Landed fix for 1.8: https://github.com/jquery/jquery/pull/808