Bug 1181392 part 7 - Remove use of IsFinishedTransition from nsTransitionManager::ConsiderStartingTransition; r=dbaron
authorBrian Birtles <birtles@gmail.com>
Fri, 07 Aug 2015 12:29:36 +0900
changeset 288403 766cbaaa78792f400079900ab1b31b02adcd6026
parent 288402 5448e9a763c47f2460ffa414ebd3e856c7e3a549
child 288404 c105cadd52e2ba00b5b87718a59c7da7eeb459df
push id5067
push userraliiev@mozilla.com
push dateMon, 21 Sep 2015 14:04:52 +0000
treeherdermozilla-beta@14221ffe5b2f [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersdbaron
bugs1181392
milestone42.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1181392 part 7 - Remove use of IsFinishedTransition from nsTransitionManager::ConsiderStartingTransition; r=dbaron Of particular note, this patch removes the check for finished transitions in the case when we can't animate the current change. This case occurs when either we have a non-transition style change that happens to coincide with the current transition value, or a style change to something we can't interpolate to. In either case it's not clear why we would cancel the existing transition only if it is still in motion and not if it is finished. It seems like it should be cancelled in either case and hence this patch removes this check. The other change relates to detecting reversing transitions. In this case we do need to distinguish between transitions that have finished and those that have not. For this purpose, checking if the animation is current should be sufficient. (Note that comparing for PlayState() == Finished would not be enough since we want to also exclude *idle*, i.e. cancelled, animations too.)
layout/style/nsTransitionManager.cpp
--- a/layout/style/nsTransitionManager.cpp
+++ b/layout/style/nsTransitionManager.cpp
@@ -565,17 +565,17 @@ nsTransitionManager::ConsiderStartingTra
              "Should have one animation property segment for a transition");
   if (haveCurrentTransition && haveValues &&
       oldPT->Properties()[0].mSegments[0].mToValue == endValue) {
     // GetAnimationRule already called RestyleForAnimation.
     return;
   }
 
   if (!shouldAnimate) {
-    if (haveCurrentTransition && !oldPT->IsFinishedTransition()) {
+    if (haveCurrentTransition) {
       // We're in the middle of a transition, and just got a non-transition
       // style change to something that we can't animate.  This might happen
       // because we got a non-transition style change changing to the current
       // in-progress value (which is particularly easy to cause when we're
       // currently in the 'transition-delay').  It also might happen because we
       // just got a style change to a value that can't be interpolated.
       AnimationPtrArray& animations = aElementTransitions->mAnimations;
       animations[currentIndex]->CancelFromStyle();
@@ -602,17 +602,17 @@ nsTransitionManager::ConsiderStartingTra
   }
 
   StyleAnimationValue startForReversingTest = startValue;
   double reversePortion = 1.0;
 
   // If the new transition reverses an existing one, we'll need to
   // handle the timing differently.
   if (haveCurrentTransition &&
-      !oldPT->IsFinishedTransition() &&
+      aElementTransitions->mAnimations[currentIndex]->HasCurrentEffect() &&
       oldPT->mStartForReversingTest == endValue) {
     // Compute the appropriate negative transition-delay such that right
     // now we'd end up at the current position.
     double valuePortion =
       oldPT->CurrentValuePortion() * oldPT->mReversePortion +
       (1.0 - oldPT->mReversePortion);
     // A timing function with negative y1 (or y2!) might make
     // valuePortion negative.  In this case, we still want to apply our