User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20100101 Firefox/14.0.1 Build ID: 20120713134347 Steps to reproduce: I created a graphical button and created a little colored triangle that, using CSS3, floats to the left, goes from transparent to opaque (AND from invisible to visible) and rotates from 180deg to 0deg when hovering over the button. Actual results: All three elements must be present for this bug to occur. On hover, the triangle becomes a blocky, noisy mess until the animation is complete. When hover is removed, all animations reverse, and the same thing occurs. Expected results: The animation worked perfectly in FF 13, but on the 14.0.1 update, it is broken. I tested this on a Windows XP machine running FF14 (Service Pack 3), on a Windows 7 machine, and on two different (slightly different) Mac OS X versions. All worked fine when using FF13, but now are broken in this regard with FF14. My client loved this animation when it worked... not so much now. I am including two files zipped - an .htm file and a .css file. Hover over the button to see the effect.

Forgot to include these graphics, which are needed to view the test html file. You'll have to create your own directory structure. See the css file included in bug.zip or put the graphics in /images so the css can find them.

I attached your testcase in one file. I tested with various versions of Firefox (8, 14, 17) on Win 7, I don't see issues with the transform and transition.

I can see the problem if HWA disabled in Firefox14.0.1 and Firefox15.0beta1. Animated element will appear as rectangle while animation. However, I cannot reproduce even if disabled HWA in Aurora16.0a2 and Nightly17.0a1. Regression window(14.0 Beta) Good http://hg.mozilla.org/releases/mozilla-beta/rev/538cf07e6ba1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 ID:20120605113340 Bad http://hg.mozilla.org/releases/mozilla-beta/rev/1cbedcda8204 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0 ID:20120612164001 Pushlog: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=538cf07e6ba1&tochange=1cbedcda8204 Regression window(15.0 Aurora) Good http://hg.mozilla.org/releases/mozilla-aurora/rev/77cf49ff4b57 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120608 Firefox/15.0a2 ID:20120608042008 Bad: http://hg.mozilla.org/releases/mozilla-aurora/rev/43d14e9a5237 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120608 Firefox/15.0a2 ID:20120608144036 Pushlog: http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=77cf49ff4b57&tochange=43d14e9a5237

Can you get a "Progression Window" against Inbound?

(In reply to XtC4UaLL [:xtc4uall] from comment #4) > Can you get a "Progression Window" against Inbound? I think there is NO "Progression Window", because Firefox4-13 works well without HWA.

This is regression in Beta and Aurora cycle. In local build(src from http://hg.mozilla.org/releases/mozilla-aurora) Last Good:ddb3b87d9384 First Bad: a125034a52b3 Triggered by a125034a52b3 Robert O'Callahan — Bug 753329. Share ThebesLayerInvalidRegion for a given ContainerLayer across all the frames that are sharing that layer as their ContainerLayer. r=mattwoodrow a=blassey * * * Bug 753329. Followup: put ThebesLayerInvalidRegionProperty in display-list-builder coordinates so it can be shared by frames with different coordinate systems. r=mattwoodrow

(In reply to XtC4UaLL [:xtc4uall] from comment #4) > Can you get a "Progression Window" against Inbound? Sorry, pls ignore comment#5. Progression Window Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/9f3534c54fa3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120713230821 Working again: http://hg.mozilla.org/integration/mozilla-inbound/rev/a7f80f6408ed Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120714005020 Push log: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9f3534c54fa3&tochange=a7f80f6408ed Progressed by Bug 772079 in Firefox16

Since we've got STR and a testcase, as well as a regression window, assigning to Chris Lord to investigate a fix. If that's not going to be possible in the next 3 weeks of the 15 beta cycle, please assign to someone else who can do the work in time.

This should be fixed on beta now since bug 772079 has been fixed there.

I'm currently at a conference at the moment (guadec), and am taking a week holiday immediately after, so it's probably a good idea to get someone else to handle this. Judging from comment #9, this will hopefully just consist of confirming that it's fixed. Adding qawanted and unassigning.

Juan - would you mind verifying? Thanks!

Fx12: Works Fx13.0.1: Works Fx14.0.1: Broken Fx15.0b2: Broken (fix in bug 772079 didn't land in time for beta 2) Fx16: Works Fx17: Works

I've also verified this on Fx15.0b3(build1).

It looks like it's fixed in Firefox 24, could we close this bug?

We should close this bug, yes.