This is necessary to get the state machine moving after it's initialized.
MediaDecoder::Load does this, but it looks like we missed this in the override.
So the current code relies on the ScheduleStateMachine call at the end of
TrackBuffer::AppendData to get things rolling. We're going to be removing that
call, so we need to fix this.
Given that we set the buffering wait to 0 in this case already, the only practical
impact on our behavior of this change is that we'll no longer ping-pong between
states.
These were accidental and redundant, because refcounted classes get this behavior
automatically. And this is very lucky, because it turns out that our MOZ_COUNT_*
infrastructure can't handle varying-sized instances identified with the same
string, which is exactly what we can get with these templated types.
The only remaining use of these macros is on the non-templated ThenValueBase,
which is happily not variable-sized. \o/
The KillHard timeout seems to be getting triggered on some of our mochitest machines, which is
causing us to leave minidumps behind - so we disable the timeout for mochitests. We also disable
KillHard paired minidumps for B2G, because we were getting minidumps for some B2G Desktop tests
there for what are likely some intentional KillHard's, and at this point, we don't think it's
worth collecting for B2G.
--HG--
extra : rebase_source : adcad58bc3b893e30e71992514b8a966257f8bc0
extra : amend_source : 11fd95ac3e3a5ed1dbb55d450f480b9092d31528
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).
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.
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.
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.
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.