There was an observable change to the timing of the first "timeupdate" in bug 1493613 - it made it occur once both of the following were true:

• it had seen a live track in the played MediaStream
• it is not paused

This is close to the definition of "potentially playing", but we need to not only wait for the first track, but until we have received a frame, i.e., once readyState is >= HAVE_FUTURE_DATA.

Before bug 1493613 we fired "timeupdate" much earlier.

See this spec issue for more details.

This led to test failures on Android when I tried to add two test cases for bug 1588507, per https://treeherder.mozilla.org/#/jobs?repo=try&&selectedJob=271145609&revision=52053a2dfa1cfb1e8f717a0f3d7b639d9dbbaf8d

It was incorrectly included in the renaming part of bug 1454998.

Depends on D49351

This makes all inputs to IsPotentiallyPlayin() Watchable when we're playing a
MediaStream.

Depends on D49352

It started progressing as soon as we set up the rendering of the tracks in the
stream, which is too early according to the HTMLMediaElement spec.

Now it starts progressing when we're potentially playing. The difference being
that we now wait for mReadyState to go beyond HAVE_CURRENT_DATA before hooking
up the time progression mechanism.

Depends on D49353

https://hg.mozilla.org/mozilla-central/rev/56eaea06b34a
https://hg.mozilla.org/mozilla-central/rev/465c7e6f7572
https://hg.mozilla.org/mozilla-central/rev/8529cff7ba28
https://hg.mozilla.org/mozilla-central/rev/a81df2957c09

What am I expected to do here? Let the WPT bitrot while I fix gecko in another bug? And if I have WPT changes in that bug, won't there be conflicts in WPT again?

Is there some workflow doc I can read up on?

There are a couple of options:

• Push more commits to this bug. They will be picked up and added to the PR. That's a good option if the test is broken or the lint is failing or similar because it means we don't end up committing broken code to master.
• Comment in the PR that the bug is known and will be fixed, and request an admin merge. That's a good option in the case like this where only Firefox is affected so we aren't making tests unstable in other browsers.

I don't think this is written down anywhere at the moment.

Thanks James.

I discussed with jib offline and we see this as a bug in the test because currentTime is allowed to change between queueing the task to dispatch canplay and actually dispatching canplay. I'll try to go with your former suggestion of pushing another commit to this bug.

https://hg.mozilla.org/mozilla-central/rev/e333a13aa5f6