Robert Schultz Reporter
	Description • 12 years ago

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.

	Robert Schultz Reporter
	Comment 1 • 12 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 12 years ago

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

	Robert Schultz Reporter
	Comment 3 • 12 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 12 years ago

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.

	Robert Schultz Reporter
	Comment 5 • 12 years ago

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.

	Robert Schultz Reporter
	Comment 6 • 12 years ago

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

	Robert Schultz Reporter
	Comment 7 • 12 years ago

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.

	Robert Schultz Reporter
	Comment 8 • 12 years ago

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.

	Robert Schultz Reporter
	Comment 9 • 12 years ago

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.

	Robert Schultz Reporter
	Comment 10 • 12 years ago

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

	Robert Schultz Reporter
	Comment 11 • 12 years ago

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

	Robert Schultz Reporter
	Comment 12 • 12 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 13 • 12 years ago

Hmm.  That's possible, perhaps, depending on how refresh ticks line up...

Robert, thanks for bisecting that!

David, thoughts?

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 12 years ago

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?

	Robert Schultz Reporter
	Comment 15 • 7 years ago

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

Closing as invalid.