[Bug 12267] <video> Make video state transitions happen in the same task as firing events

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

--- Comment #36 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2011-07-15 22:48:33 UTC ---
(In reply to comment #35)
> (In reply to comment #34)
> > The problem that when an event fires, there are no guarantees about what state
> > the element is actually in
> 
> There is no way we can fix this in a non-confusing way. For example, say that a
> 'timeupdate' event fires and currentTime is t=5. The script sets a cue with
> pauseOnExit set for a time of t=6. But really, the time when the script does
> this is t=7. Are you saying we should somehow warp the video back to t=6 and
> pause?

In Gecko, after the cue has been set up, an internal task updates currentTime
from 5 to 7, and the cue handler would run and pause the media when the real
playback time is something greater than 7.

Of course, the same result is possibly with pretty much any implementation. For
example, the script might call currentTime and get t=5, sets a cue for t=6, the
cue handler runs, but the handler's pause call doesn't happen until the real
playback time is greater than 7. So Gecko's behavior is certainly no worse
here.

However, in some implementations it's entirely possible that once in a while
the script sees currentTime=5, sets a cue for t=6 after the currentTime has
advanced to 7, and then the cue never fires. So Gecko guarantees that with this
code, the cue always fires, but with other implementations we could easily have
a situation where the cue almost always fires but once in a while it doesn't. I
think it's clear that this is bad. I think Gecko's behavior is clearly better
here.

More coming...

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 15 July 2011 22:48:35 UTC