850320 - initiating a css3 transition on a transitionend event causes the element to jitter

Status: RESOLVED DUPLICATE of bug 849399

(Core :: CSS Parsing and Computation, defect)

Description

[21echoes]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20130301 Firefox/21.0
Build ID: 20130301042013

Steps to reproduce:

Have a javascript function which starts a css3 transition
bind that function to transitionend on the element you are transitioning
run the first transition to start the loop


Actual results:

when starting the next transition, the div will first jump to its final destination of the transition before jumping back to where it was and then animating there smoothly

after googling around for solutions, i found someone with a similar problem who had posted a great test case: http://umamie.com/csstransition/cssTweenDemo.html


Expected results:

the element should not jump to its final state before jumping back then animating

Comment 1

[Loic]

Confirmed with FF19 on Win 7 too. Same issue with HWA on/off.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This seems like the sort of thing that should be done with animations, not transitions.  The observed behavior is perfectly valid per the transitions spec...

This is also why https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html is being developed.

Comment 3

[21echoes]

(In reply to Boris Zbarsky (:bz) from comment #2)
> This seems like the sort of thing that should be done with animations, not
> transitions. 

i thought the *whole point* of css3 transitions was to allow smooth movement of elements from one state to another without resorting to the javascript overhead of running an animation loop?

> The observed behavior is perfectly valid per the transitions
> spec...

can you point me to the part of the transitions spec where it says "when transitioning, an element may randomly flash to any point on its traversal curve"?

> This is also why
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html is being
> developed.

if you read the first paragraph of that link, you will see "CSS Transitions, [CSS Animations, and SVG] provide mechanisms that generate animated content on a Web page. [...] This specification proposes an abstract animation model that encompasses the common features of all three specifications. This model is backwards-compatible with the current behavior of these specifications"? In other words, the Web Animation spec has no effect on this bug. The Web Animation spec is just a superset of the existing CSS3 transition spec, so any bugs in Firefox's adherence to the CSS3 transition spec would remain.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to 21echoes from comment #3)
> (In reply to Boris Zbarsky (:bz) from comment #2)
> > This seems like the sort of thing that should be done with animations, not
> > transitions. 
> 
> i thought the *whole point* of css3 transitions was to allow smooth movement
> of elements from one state to another without resorting to the javascript
> overhead of running an animation loop?

bz was referring to http://dev.w3.org/csswg/css3-animations/

> > The observed behavior is perfectly valid per the transitions
> > spec...
> 
> can you point me to the part of the transitions spec where it says "when
> transitioning, an element may randomly flash to any point on its traversal
> curve"?

I don't have a comment here; the test looks like it will take me about 10 minutes to understand, which I don't have right this minute.

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: testcase

current contents of http://umamie.com/csstransition/cssTweenDemo.html

Comment 6

[21echoes]

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #4)
> (In reply to 21echoes from comment #3)
> > (In reply to Boris Zbarsky (:bz) from comment #2)
> > > This seems like the sort of thing that should be done with animations, not
> > > transitions. 
> > 
> > i thought the *whole point* of css3 transitions was to allow smooth movement
> > of elements from one state to another without resorting to the javascript
> > overhead of running an animation loop?
> 
> bz was referring to http://dev.w3.org/csswg/css3-animations/

got it. css3 keyframe animations will not work because the animation's full path is not known at any one point in time. in the test case i found on stackoverflow, this can be seen in that the next location is random. one can easily imagine a case where user input can modify the animation, and changing css3 keyframe animations while the animation is running is, to my knowledge, not well supported (and certainly more complex than just queueing another transition)

> 
> > > The observed behavior is perfectly valid per the transitions
> > > spec...
> > 
> > can you point me to the part of the transitions spec where it says "when
> > transitioning, an element may randomly flash to any point on its traversal
> > curve"?
> 
> I don't have a comment here; the test looks like it will take me about 10
> minutes to understand, which I don't have right this minute.

yea, whoever wrote the test case could have made it much more straightforward. i could have taken the time to write my own, but i felt once understood it quite plainly laid out the problem. the main bit is to ignore the exec function other than the part where it actually writes the x and y values into the transform property. again-- this bug happens any time one initiates a new css3 transition on the transitionend event of a previous one.

Comment 7

[boubiyeah]

So is it a bug or not? Whatever it is, it does work fine on Chrome :-)
This is actually a very common scenario: Computing a sequence of transitions with dynamic values; It would be great if we didn't have to wait 5 more years for browsers to support web animations without too many bugs, to achieve this fairly basic effect!

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

So in my testing, this was fixed somewhere between the Linux mozilla-central nightlies from 2013-06-18 and 2013-06-19, giving the fix range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4e5983de6e3b&tochange=d2a7cfa34154

(This means the fix will be in Firefox 24.)