If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Adding new CSS TransitionProperty during transition, causes graphical glitch

NEW
Unassigned

Status

()

Core
Layout
5 years ago
5 years ago

People

(Reporter: Robert Schultz, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 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.
(Reporter)

Comment 1

5 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.)
Seems to work fine for me in a Mac nightly and in Firefox 13 on Mac...
(Reporter)

Comment 3

5 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.
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.
(Reporter)

Comment 5

5 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.
(Reporter)

Comment 6

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

Comment 7

5 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.
(Reporter)

Comment 8

5 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.
(Reporter)

Comment 9

5 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.
(Reporter)

Comment 10

5 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
(Reporter)

Comment 11

5 years ago
Here is the change set link: http://hg.mozilla.org/mozilla-central/rev/04e2d8313601
(Reporter)

Comment 12

5 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.
Hmm.  That's possible, perhaps, depending on how refresh ticks line up...

Robert, thanks for bisecting that!

David, thoughts?
Blocks: 716549
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
You need to log in before you can comment on or make changes to this bug.