This test is fundamentally racey - it loads very short video files (some less
than 1s), plays them, waits for timeupdate events to try to find just the right
moment to seek, performs a seek, and then checks various pieces of
playback-dependent state (while playing).
The specific issue I ran into was that the video would sometimes finish playing
before the 'seeked' event handler fired, which means that readyState is
HAVE_CURRENT_DATA (per spec). I could fiddle with the test a bit to handle this
case, but I think we're doing a disservice to ourselves by having it in the tree.
The use of play() and pause() in the test is hugely problematic for short video
files and slow/laggy platforms. In particular, if playback has ended by
the time that we fire the 'seeked' event listener, then the ensuing play() will
put us back into seeking mode (seeking to 0), making the test fail.
This means that we can get rid of the code to recheck state after dropping the
monitor. We'll remove the other monitor drop from this method in a subsequent
patch.
This has two implications:
* We no longer need to pipe mQueuedSeekTarget through MDSM::Seek to get the
appropriate clamping.
* MDSM::Seek doesn't _need_ to be called on the main thread anymore.
The ogg reader makes two adjustments to the seek time - the first is to clamp it
between start and end time, which MDSM already does. The second is to subtract
SEEK_OPUS_PREROLL from the target. If we wanted to, we could return this as the
resolve value in the seek promise and handle the update in the MDSM. But I think
DropVideoUpToSeekTarget should actually handle this just fine.
The model we're moving towards is one where the MDSM can just disconnect all of
its promises, send a ResetDecode down the pipe, and start doing something
unrelated.
I traced this back to something 2011 or earlier and then gave up. Given that we're
doing an exact microsecond comparison here this is almost certainly dead code in
every case except for the one where the media is paused and JS does
|el.currentTime = el.currentTime|. And in that case, I think running through the
regular seek machinery is probably fine.
Add an ObjectOpResult out-param for DefineProperty functions everywhere. We leave a few js::DefineProperty() convenience functions with no *result out-param. These have strict behavior: that is, they automatically check the result and throw if it is false. In bug 1125624 these strict signatures may end up being called DefinePropertyOrThrow, as that is what the spec calls it.
In general, jsobj.h will offer, for each standard internal method that returns a boolean value indicating success/failure, signatures with a JS::ObjectOpResult& out-parameter and signatures without it. The ones without will throw a TypeError on failure (that is, the behavior will be "strict").
