Reproduction test case: http://jsfiddle.net/xCfs9/15/ Press 'Go' button. It happens 90% of the time. Use 'Run' button at top to reset. Seen on 14.0.1 Linux, 14 on Windows and 13.0.1 on Linux. Report of it not happening on 15b 1. Use CSS transitions to animate the left and top of an <img> over 5 seconds 2. 2.5 seconds into it, apply a third CSS transition, a Transform 3. Should be silky smooth, and is in Chrome and Opera But in Firefox when the rotation starts, it briefly 'blinks' to it's final rotation destination before flicking back and rotating correctly. Work-Around test cast: http://jsfiddle.net/xCfs9/14/ If you add the future TransitionProperty at the beginning, it appears to prevent the 'glitch' from happening when the Rotation starts.

Just installed Firefox 15.0 on Linux, still glitchy (Build identifier: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.)

Seems to work fine for me in a Mac nightly and in Firefox 13 on Mac...

I have tested with multiple Firefox versions (obtained from https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/) All are i686 on Linux. 11.0 - WORKS! 12.0 - BUGGY (Only 10% of time) 13.0 - BUGGY (90% of time) 13.0.1 - BUGGY (90% of time) 14.0.1 - BUGGY (90% of time) 15.0b2 - BUGGY (90% of time) So something happened at 12.0 to start causing it and something in 13.0 made it much much worse.

Interesting. Are you willing to try some nightly builds to narrow this down to a one-day set of checkins? There's a tool at http://harthur.github.com/mozregression/ that automates this somewhat.

So bad news, it happens in 11.0 as well, just far less often. Could only get it to happen twice with a large number of tries. I'm going to go back further, then I will try Boris' suggestion at determining which day's check in caused it.

Also, I'll try and come up with a more reliable (100%) reproduction.

Ok, new test case: http://jsfiddle.net/xCfs9/17/ On FF 13.0 it glitches lots. On FF 12.0 I saw zero glitches. I will be trying to narrow it down to a single nightly build as Boris Zbarsky suggested.

Last good nightly: 2012-01-14 First bad nightly: 2012-01-15 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3eaa7d9f1c69&tochange=21c84409902e I am further bisecting and will update once I narrow down something closer.

Attempting to bisect to a commit, yielded an impossible state. So I built a stand-alone test: http://telparia.com/ffcsstransformbug.html I then re-tested regression and this time I got: Last good nightly: 2012-01-09 First bad nightly: 2012-01-10 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a230265bad5&tochange=c713003d3226 I am now attempting to bisect further.

Success! The first bad revision is: changeset: 84042:04e2d8313601 user: Boris Zbarsky <bzbarsky@mit.edu> date: Fri Dec 23 22:52:26 2011 -0500 summary: Bug 716549. Flush on every mousemove, because otherwise we can end up with mouse events (mousemove, mousein, mouseout) dispatched to the wrong elements. r=smaug Regression found using mozcommitbuilder 0.4.10 on linux2 at 2012-07-27 12:56:38

Here is the change set link: http://hg.mozilla.org/mozilla-central/rev/04e2d8313601

I guess this is why it didn't happen all the time, you need to move your mouse around while the test case is running. I know nothing about how the FF code works underneath, but if I had to guess, I'd say the 'FlushPendingEvents(aPresContext)' is some how rendering the element at it's final state for a split second, before the CSS transitioning code takes back over and returns it to it's previous state to correctly animate it to it's final state. Just a guess though.

Hmm. That's possible, perhaps, depending on how refresh ticks line up... Robert, thanks for bisecting that! David, thoughts?

Oh, and the one thing that confuses me is that invalidates should _also_ come via refresh ticks, I thought. So why is any sort of intermediate state getting painted?

This bug is no longer valid in Firefox 56, was probably fixed long before then, etc. Closing as invalid.