Bug 1070745 part 1 - Factor out new_div etc. to animation_utils.js; r=dholbert

We use new_div, check_events etc. in a number of animation-related mochitests
and with this bug we'll want to use them in a few more. This patch factors them
out into animation_utils.js and tidies them up a little.
Bug 1070745 part 2 - Update AnimationPlayer IDL to enable play() and pause(); r=bz

We map play()/pause() to PlayFromJS/PauseFromJS internally so that internal
users don't accidentally call Play()/Pause() which flush style.
Bug 1070745 part 3 - Convert AnimationPlayer mPlayState to an mPaused bool; r=birtles

We only need to store if an animation is paused or not, hence a bool is
sufficient. Furthermore, the convenience of using the same type as the specified
style of animation-play-state will disappear once pausing behavior is wrapped up
behind Play() and Pause() methods.
Bug 1070745 part 4 - Add AnimationPlayer::Play and AnimationPlayer::Pause; r=dholbert

This patch introduces the basic implementation of play() and pause().

There are a lot of gaps still because we don't yet:
* Support the pending state (to be covered in bug 927349)
* Support finishing behavior (to be covered in bug 1074630)
* Have a good way of updating animation state outside of style resolution (bug
  1073336)

Also, we don't call these methods from CSS yet because the interaction between
play()/pause() and animation-play-state requires storing some extra state which
we introduce in subsequent patches in this series.

This patch introduces, temporarily, an update flag to indicate whether
play()/pause() operations need to post a restyle event. When these methods are
triggered by processing restyles we don't want to post another (unnecessary)
restyle event. In bug 1073336 we will remove the need for this.
Bug 1070745 part 5 - Add CSSAnimationPlayer subclass; r=dholbert

This patch introduces a CSSAnimationPlayer subclass of AnimationPlayer. This is
because when we have an animation player running a CSS animation it has some
special behavior not needed in the general case such as:

* Flushing style before performing certain operations to ensure we are using
  the latest information.
* Dispatching CSS Animation events when we start/end.
* Storing extra state with regards to "how" the animation was paused.
  This is because, for example, if an animation is paused by script this
  overrides specified style.
Bug 1070745 part 6 - Add means of marking a CSSAnimationPlayer as being paused by style; r=dholbert

When an animation player is paused by script this overrides whatever
animation-play-state is set by style. The logic for producing the correct
override behavior will be added to nsAnimationManager but first we need
to record in the player where it was paused.
Bug 1070745 part 7 - Add style flush at the beginning of Play(); r=dholbert

For players running CSS animations and CSS transitions we should perform a style
flush before running play() so that we are operating on the most up-to-date
state of animation-play-state.

For transitions, which don't have a play-state property, we will still need to
run this style flush before running play() to get the right finishing behavior
if transition-duration has changed. We haven't implemented finishing yet (that's
bug 1074630) but I've kept the flush for both cases now since I'm afraid we'll
forget it later.

Also, since we don't have a subclass of AnimationPlayer for transitions yet I've
put the style flush in the base class. In future, when we add
CSSTransitionPlayer we can move the flush to only those players that need up to
date style information.
Bug 1070745 part 8 - Use play/pause from nsAnimationManager; r=dholbert

This patch uses the PlayFromStyle/PauseFromStyle methods on CSSAnimationPlayer
to perform play/pause control. (This allows us to encapsulate mHoldTime and
mPaused. We will encapsulate mStartTime etc. in subsequent bugs.

The override behavior of play()/pause() with regard to animation-play-state is:
* pause()/play() override the current animation-play-state
* pause() causes the player to remain paused until play() is called regardless
  of changes to animation-play-state
(* Calling play() will override the animation-play-state but won't "stick". i.e.
   subsequently setting animation-play-state: paused will pause the animation.)

These different permutations are tested in the next patch in this series.

This interaction will probably become more complicated once we introduce
finishing behavior (since we might not want animations to restart when
setting animation-play-state: running).
Bug 1070745 part 9 - Tests for play/pause behavior; r=dholbert
Bug 1037321 - Implement playState on AnimationPlayer; r=birtles, r=bz
Bug 1078119 - Rename AnimationTimeline/AnimationPlayer GetCurrentTimeDuration; r=bz

This patch performs the following renaming:

  AnimationPlayer::GetCurrentTime -> GetCurrentTimeAsDouble
  AnimationPlayer::GetCurrentTimeDuration -> GetCurrentTime
  AnimationTimeline::GetCurrentTime -> GetCurrentTimeAsDouble
  AnimationTimeline::GetCurrentTimeDuration -> GetCurrentTime
Bug 1078122 part 1 - Move checks for animation throttling to AnimationPlayer; r=dholbert

This patch moves code from AnimationPlayerCollection to AnimationPlayer.

However, there is one subtle change in logic involved. Previously, we would test
if the player had finished by getting the computed time of its source content
and checking if it was in the after phase or not. In this patch, however, we
simply check the play state to see if it is finished or not.

These two approaches differ in the case where an animation is paused after it
has finished. The animation phase approach will indicate the player has
finished, but the play state approach will indicate the player has paused (since
the "paused" state trumps the "finished" state). This, however, should not
produce any observable effect because when an animation is paused
mIsRunningOnCompositor will be false (we don't put paused animations on the
compositor).
Bug 1078122 part 2 - Encapsulate mIsRunningOnCompositor in AnimationPlayer; r=dholbert
Bug 1078122 part 3 - Move animation value building down to the Animation objects; r=dholbert

This patch extracts the logic for calculating animation styles from
AnimationPlayerCollection and puts the bulk of it into the Animation objects.
Some of the initial logic surrounding the animation player state (e.g. is it
paused or not, etc.) is put into AnimationPlayer.

In future we may shift this logic even further down to the AnimationEffect
objects but currently we don't create such objects unless necessary.
Bug 1078122 part 4 - Make the mSource and mTimeline members of AnimationPlayer protected; r=dholbert
Bug 1078122 part 5 - Move CSSAnimationPlayer to nsAnimationManager; r=dholbert

This patch takes the CSSAnimationPlayer object, currently defined in
dom/animation/AnimationPlayer.{cpp,h}, and moves it to
layout/style/nsAnimationManager.{cpp,h} where the rest of the CSS
Animations-specific code lives.

At the same time it extends the scope of the mozilla namespace block in
nsAnimationManager.h to also include the AnimationEventInfo and EventArray types
since these classes, which don't have an ns* prefix, probably should be in the
mozilla namespace anyway.
Bug 1078122 part 6 - Store the previous finished state; r=dholbert

AnimationPlayer::CanThrottle determines if an animation player has just finished
by inspecting the value of mLastNotification. This is problematic for two
reasons:

1. mLastNotification is intended to be used for events (as the XXX comment
   notes)
2. mLastNotification is specific to CSS Animations and should be moved to
   CSSAnimationPlayer.

To address this, this patch adds an extra member mIsPreviousStateFinished. The
Web Animations spec already defines animation players as having such a member:

  http://w3c.github.io/web-animations/#previous-finished-state

We set it to true when we calculate the style for an animation that has
finished. This differs slightly from the code it is replacing as explained
below.

In the case of CSS Animations we perform the following sequence of steps on each
sample.

  1. EnsureStyleRuleFor (calls CanThrottle, and maybe ComposeStyle)
  2. GetEventsForCurrentTime

In the existing code, we update mLastNotification in (2) which happens on every
sample, even throttled samples.

In this patch, however, we update mIsPreviousStateFinished in (1) during the
ComposeStyle step which only happens for unthrottled samples. So, as of this
patch, in CanThrottle, we ask "have we newly entered the finished state since
the last *unthrottled* sample?", whereas previously we simply looked for
a change since the last sample, throttled or not. However, if the answer to the
question is "yes", then we'll run an unthrottled sample and update
mIsPreviousStateFinished so these should be functionally equivalent.

Another subtle difference is that this patch looks at the player's finished
state rather than the animation phase of its source content, and these will
produce different results in the case where the player is paused. However, since
paused animations are not run on the compositor, this should not matter.

In the case of CSS Transitions, AnimationPlayer::CanThrottle() is not currently
used and so mIsPreviousStateFinished is irrelevant.

Ultimately, both the existing and the new code is somewhat fragile but hopefully
this will be addressed by:
* Replacing mIsPreviousStateFinished with inspecting whether the finished
  promise is settled (bug 1074630),
* Merging more of the code in nsAnimationManager and nsTransitionManager and
  applying a unified approach to sampling that better accommodates these
  considerations.
Bug 1078122 part 7 - Add method to Animation to get the target element and pseudo; r=dholbert
Bug 1078122 part 8 - Use the new GetTarget overload in AnimationPlayer; r=dholbert
Bug 1078122 part 9 - Move queuing of CSS animation events to CSSAnimationPlayer; r=dholbert

This patch moves the code for queuing CSS animation events from
nsAnimationManager to CSSAnimationPlayer. In doing so, it also moves the
mLastNotification member and associated enum values.