Bug 1206345 - Force a state update in browser_animation_reconstructState.js; r=jdescottes

This test wasn't using refreshState, instead it used getCurrentState.
What refreshState does on top of getCurrentState is it stores the new state
locally.
getCurrentState isn't meant to be called externally, it is only meant to be
an actor method interceptor that reconstructs the missing state.
So the test should have used refreshState from the start.

Turns out it worked in most cases because the animation did have a startTime
when the test retrieved it, so it had a previousStartTime.
But, if for some reason, the animation has a startTime=null when the test
starts, then the value never gets to the front, and bad things happen.

MozReview-Commit-ID: 2nEIKHMHsCS

--HG--
extra : rebase_source : 14d896fe895876346f1d52c3e8f72880d5bdfec6

devtools/server/tests/browser/browser_animation_reconstructState.js

@@ -7,7 +7,7 @@
 // Check that, even though the AnimationPlayerActor only sends the bits of its
 // state that change, the front reconstructs the whole state everytime.
 
-add_task(function*() {
+add_task(function* () {
   let {client, walker, animations} =
     yield initAnimationsFrontForUrl(MAIN_DOMAIN + "animation.html");
 
@@ -29,9 +29,9 @@ function* playerHasCompleteStateAtAllTimes(walker, animations) {
   // contains all keys.
   // Normally, only the currentTime will have changed in between 2 calls.
   for (let i = 0; i < 10; i++) {
-    let state = yield player.getCurrentState();
+    yield player.refreshState();
     keys.forEach(key => {
-      ok(typeof state[key] !== "undefined",
+      ok(typeof player.state[key] !== "undefined",
          "The state retrieved has key " + key);
     });
   }