###!!! ABORT: timing fraction should be in [0-1]: '0.0 <= computedTiming.mTimeFraction && computedTiming.mTimeFraction <= 1.0', file layout/style/AnimationCommon.cpp, line 909 (CCing Brian Birtles, who fixed bug 1028514, which hit the same assertion)

Looks like another overflow case. I've got some patches for bug 1039924 which may fix this.

(In reply to Brian Birtles (:birtles) from comment #2) > Looks like another overflow case. I've got some patches for bug 1039924 > which may fix this. They don't, unfortunately fix this. This test case sets up an animation that repeats forever with a delay that is equal to INT64_MIN. In ElementAnimation::GetComputedTimingAt we decide the animation is in the active phase and go to calculate the active time: activeTime = localTime - aTiming.mDelay; localTime is initially zero which means we calculate 0 - INT64_MIN with both arguments of type int64_t. Since INT64_MIN in two's complement is -9223372036854775808 but INT64_MAX is 9223372036854775807 we end up back at INT64_MIN. That is, we have a negative active time which shouldn't happen (normally if active time would have been zero according to the above formula we would have decided we are in the "before phase" and clamped the active time to zero). From that point on all the other calculations fall apart. We could do a localized solution for this particular case but I think it's probably a reasonable arrangement: a infinitely repeating animation that has a negative delay that makes it start from negative infinity. So I think the way I'd like to solve this is: 1. Update the Web Animations spec to handle this case. It should probably line up the active time such that a new iteration starts at the player start time. It should probably set the current iteration to positive infinity in all cases. 2. Convert mDelay to a SaturatingTimeDuration (once bug 1039924 lands). 3. Add special handling as necessary. 4. Write tests for this case (probably need to implement getComputedTiming). Once we support setting player start times we'll need to handle negative infinity there too. I'm not sure how that should work though.