Bug 1125455 patch 7 - For compositor-thread application of transitions, don't apply transitions when animations are also running. r=birtles

I've verified locally that this patch (not others in this series) fixes
the test failures that match the test changes in this patch.

layout/base/nsDisplayList.cpp

@@ -424,6 +424,18 @@ AddAnimationsForProperty(nsIFrame* aFrame, nsCSSProperty aProperty,
       continue;
     }
 
+    if (!property->mWinsInCascade) {
+      // We have an animation or transition, but it isn't actually
+      // winning in the CSS cascade, so we don't want to send it to the
+      // compositor.
+      // I believe that anything that changes mWinsInCascade should
+      // trigger this code again, either because of a restyle that
+      // changes the properties in question, or because of the
+      // main-thread style update that results when an animation stops
+      // filling.
+      continue;
+    }
+
     // Don't add animations that are pending when their corresponding
     // refresh driver is under test control. This is because any pending
     // animations on layers will have their start time updated with the

layout/style/test/test_animations_omta.html

@@ -2149,10 +2149,10 @@ addAsyncAnimTest(function *() {
           "opacity transition at 0.5s");
   gDiv.style.animation = "opacitymid 2s linear";
   yield waitForPaintsFlushed();
-  omta_todo_is("opacity", 0.2, RunningOn.Compositor,
+  omta_is("opacity", 0.2, RunningOn.Compositor,
           "opacity animation overriding transition at 0s");
   advance_clock(500);
-  omta_todo_is("opacity", 0.35, RunningOn.Compositor,
+  omta_is("opacity", 0.35, RunningOn.Compositor,
           "opacity animation overriding transition at 0.5s");
   done_div();
 });