Skip to main content

Bug Tracker

Side navigation

#7109 closed bug (fixed)

Opened October 01, 2010 11:04PM UTC

Closed June 11, 2012 06:27PM UTC

animate width starts with invalid width on webkit

Reported by: kellyfelkins Owned by: gibson042
Priority: blocker Milestone: 1.8
Component: effects Version: 1.4.2
Keywords: Cc: snover
Blocked by: Blocking:
Description

This works nicely in firefox.

Not so nice in chrome and safari.

If you change width via animate, it appears the start of the animation is incorrect (too large).

The item is sitting there at a certain width, say "30%". If you animate it, changing its width to 0% it appears to first jump to about 60%, then animate smoothly to zero.

Attachments (1)
  • animate.html (0.4 KB) - added by kellyfelkins October 01, 2010 11:04PM UTC.

    animates a div from 30% to 1% width. Has initial bump on webkit

Change History (19)

Changed October 02, 2010 05:12AM UTC by snover comment:1

cc: → snover
component: unfiledfx
need: ReviewPatch
priority: undecidedlow

Changed October 14, 2010 05:57AM UTC by snover comment:2

status: newopen

Changed November 12, 2010 02:40AM UTC by snover comment:3

milestone: 1.4.3

Resetting milestone to future.

Changed November 29, 2010 10:25PM UTC by aivo@iteral.com comment:4

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.

Changed March 15, 2011 01:16AM UTC by anonymous comment:5

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.

Changed April 17, 2011 08:24PM UTC by timmywil comment:6

milestone: → 1.next

Changed July 12, 2011 07:57PM UTC by gnarf comment:7

_comment0: 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 these two fiddles: http://jsfiddle.net/GVFah/3/ (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?1310500696584469
_comment1: 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 these two fiddles: http://jsfiddle.net/GVFah/3/ (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?1310500714702578
_comment2: 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 these two fiddles: http://jsfiddle.net/GVFah/3/ (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?1310500851272717
_comment3: 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 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?1310500887603737

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?

Changed June 03, 2012 09:26AM UTC by jeff_themovie comment:8

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

Changed June 04, 2012 12:40PM UTC by mikesherov comment:9

milestone: 1.next1.8
priority: lowblocker

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/

Changed June 04, 2012 04:52PM UTC by mikesherov comment:10

owner: → mikesherov
status: openassigned

Changed June 04, 2012 08:17PM UTC by gibson042 comment:11

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

Changed June 04, 2012 08:56PM UTC by mikesherov comment:12

owner: mikesherovgibson042

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

Changed June 04, 2012 09:07PM UTC by gibson042 comment:13

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

Changed June 04, 2012 09:46PM UTC by mikesherov comment:14

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

Changed June 04, 2012 09:49PM UTC by mikesherov comment:15

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

Changed June 04, 2012 10:09PM UTC by gibson042 comment:16

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.

Changed June 05, 2012 05:15PM UTC by jeff_themovie comment:17

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.

Changed June 05, 2012 07:21PM UTC by gnarf comment:18

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

Changed June 11, 2012 06:27PM UTC by dmethvin comment:19

resolution: → fixed
status: assignedclosed