Bug 927349 part 8 - Fast-forward the timeline before resolving start times; r=jwatt

Normally animation players get times from their timeline which is based on the
refresh driver for their associated document. However, for animations that
we time from when their first frame has been rendered, we want to record the
actual time when painting finished as their start time. If we wait until the
next refresh driver tick then the delay between playing an animation and its
actual start will be too great.

In this patch, we introduce a mechanism for fast-forwarding a timeline to a
time between the current refresh driver time and the next refresh driver tick.
By adjusting the timeline rather than the player we maintain a consistent state
(in fact, if we just naively set the animation player start time to the
timestamp value we recorded when painting finished it will appear to start in
the future and the animation will temporarily jump from playing, to waiting to
start, then back to playing again on the next refresh driver tick).

To be completely consistent, however, when we fast-forward the timeline we
should tell all animation players listening to the timeline to mark their
target element as needing a style flush. Otherwise we may be able to observe an
inconsistency between some animation players' current time and the computed
style of their targets.

We don't, however, currently know which players are observing a given timeline.
We will likely introduce that in the near future (in order to implement
AnimationTimeline.getAnimationPlayers) and fix the inconsistency in timing then.
A test later in the patch series verifies this inconsistency so it is easy to
fix in future.

An alternative approach would be to simply record the time when animation should
start, send that time to the compositor but don't actually update the animation
start time on the main thread until the subsequent refresh driver tick. Such
an approach is complex as it introduces an additional state--"finished pending
but not yet started". We will attempt to switch to that approach in bug 1112480.
Bug 927349 part 9 - Add PendingPlayerTracker::StartPendingPlayers; r=jwatt
Bug 927349 part 10 - Record the time when animations are ready to start; r=jwatt
Bug 927349 part 11 - Pass the animation ready time to the pending player tracker; r=jwatt
Bug 927349 part 12 - Store the initial time of animations on layers so start times can be resolved after-the-fact; r=nical
Bug 927349 part 13 - Update start times on animations in layers when the animation ready time is resolved; r=nical
Bug 927349 part 14 - Store reference to owning document on PendingPlayerTracker; r=jwatt

This patch adds a reference from PendingPlayerTracker back to the document
object that owns it. This is used in the next patch in this series to find the
document's root frame for scheduling a paint.
Bug 927349 part 15 - Schedule a paint when a new pending animation is added; r=jwatt

We would like to trigger animations from the point when the first frame of the
animation is painted. However, some animations will never trigger a paint (e.g.
animations with an empty keyframes rule). These animations should start start
however. To ensure this, whenever an animation is newly pending we schedule
a paint.
Bug 927349 part 16 - Do a full reflow when we have pending animations; r=jwatt

We want to time animations from when their first frame is painted. However,
interruptible reflow complicates this since, for a given set of pending
animations, some may be painted whilst others are not. To simplify this we
simply force an uninterruptible reflow when we have animations that are
waiting to start.
Bug 927349 part 17 - Don't count native reflows in test_popupreflows.xul; r=markh

test_popupreflows.xul currently expects to get 1 reflow when a popup is opened.
This is triggered by JS code. An incremental layout may be triggered by native
code but the test ignores that for unclear reasons ("Because we've simply
cargo-culted this test from browser_tabopen_reflows.js!").

In part 16 on this patch series, we force interruptible reflows to become
full reflows when we have pending animations which can cause this test to
fail since it will see 2 reflows.

The above quoted browser_tabopen_reflows.js specifically ignores reflows
triggered by native code so we adjust this test to do likewise.
Bug 927349 part 18 - Make nsDOMWindowUtils::AdvanceTimeAndRefresh trigger any pending animations first; r=jwatt

Currently many tests rely on nsDOMWindowUtils::AdvanceTimeAndRefresh. These
tests assume that the animation starts from the moment it is created. In order
to allow these tests to continue to operate without change we make
AdvanceTimeAndRefresh force any pending animations to start.
Bug 927349 part 19 - Don't add pending animations to layers when their refresh driver is under test control; r=jwatt
Bug 927349 part 20 - Update selectTreeItem to wait for tree expansion animations to finish; r=bgrins

Currently selectTreeItem, as used by various devtools storage panel tests,
expands the tree then clicks items. However, it fails to account for the fact
that expansion animations may mean that the item that should be selected is not
yet able to be clicked. It currently happens to be lucky enough that typically
the animation is short enough that the item in question will be click-able in
time (since click() spins the event loop using executeSoon there is some time
for the animation to play).

If we make animations wait until their first frame has rendered before
beginning the chance that the tree item will become clickable in time is
reduced. This patch works around that by looking for animating branches
amongst the ancestors of the item to be selected. If one is found it waits for
the animation to end.

Unfortunately this ties the tests to the tree widget styles somewhat (in
particular the test looks for specified values of max-height).
However, these changes only delay the execution of the test so, if these styles
were to change, it is only likely that these tests would fail (and hence need to
be updated) than to mask a genuine bug. Until the Web Animations API is
available by default it is difficult to test if animations are running so this
seems like the best we can do for now.
Bug 927349 part 21 - Factor out AnimationPlayer::UpdateSourceContent; r=jwatt

In the future we will want to specifically just update source content without
necessarily triggering any other actions that might take place on a tick (like
queuing events).