Bug 986359 part 1 - Move SetTestSampleTime and LeaveTestMode to LayerTransactionParent; r=mattwoodrow
Bug 986359 part 2 - Factor out GetTransaction in DOMWindowUtils; r=mattwoodrow
Bug 986359 part 3 - Add AutoResolveRefLayers before calling TransformShadowTree; r=mattwoodrow
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
Bug 975261 part 2 - Trigger animations with a delay; r=dzbarsky

Animations with a delay are not put on the compositor thread until the end of
the delay phase. However, there is currently nothing that explicitly triggers
this transaction. It may occur due to flushes that arise from UI events but it
is not guaranteed.

This patch detects the end of a delay phase and turns off throttling for that
sample. It re-uses the mLastNotification member which is not ideal but
a subsequent patch in this queue removes this and replaces it with the approach
used for transitions.
Bug 975261 part 3 - Add test for transforms; r=dzbarsky

Adds a test for transform animations with a delay where there is already
a transform specified on the element.

This test used to fail but bug 828173 fixed it. It is included here as
a regression test.

(Prior to bug 828173 we were able to fix this by triggering
ForceLayerRerendering inside nsAnimationManager::nsFlushAnimations whenever we
detected *different* style rules but canThrottleTick=true)

The issue stemmed from the fact that when an element has a transform property,
LayerIsPrerenderedDataKey would get set on the layer because in
nsDisplayTransform::ShouldPrerenderTransformedContent we would only check for
the *presence* of an animation, not whether it is running. Then in
RestyleManager::DoApplyRenderingChangeToTree we wouldn't do an invalidating
paint because TryUpdateTransformOnly() returns true since it looks at
LayerIsPrerenderedDataKey.

Bug 828173 fixes this, at least in part, by checking if an animation is running.
This bug may resurface if we put animations with a delay on the compositor
thread hence it is worth including here.
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky

This test reproduces a bug where we don't send an animation to the compositor
thread. The important step is the sample precisely at the start of the animation
interval.
Bug 975261 part 5 - Fix OMTA animations with backwards fill; r=dzbarsky

When we have a backwards fill and we sample at *exactly* the start of the
animation on the next refresh driver tick, when we get to
RestyleManager::ComputeStyleChangeFor (or more specifically
ElementRestyler::CaptureChange) we notice that the style hasn't changed (since
the first frame of the animation produces the same value as the backwards fill)
and end up with an empty change list. As a result we never schedule a view
manager flush and rebuild the layer. Hence, the animation never gets sent to the
compositor thread. On the next tick we're already throttling the main thread.

This patch fixes this by applying the same approach as is used for transitions,
that is, explicitly marking which animations are running on the compositor
thread so we know if we need to trigger a layer transaction or not. This should
not only be more robust than the previous code but also facilitate aligning
animations and transitions code (bug 880596).
Bug 981508 - Fix comment in nsDisplayTransform::ShouldPrerenderTransformedContent; r=roc