[whatwg] Asynchronous events observe unexpected states in media elements

[Robert O'Callahan]

Media element state changes, such as readyState changes, trigger
asynchronous events. When the event handler actually runs, the element state
might have already changed again. For example, it's quite possible for
readyState to change to HAVE_ENOUGH_DATA, a canplaythrough event is
scheduled, then the readyState changes to HAVE_CURRENT_DATA, then the
canplaythrough event handler runs and may be surprised to find that the
state is not HAVE_ENOUGH_DATA.

A related surprise is that although a media element delays the document load
event until the readyState reaches HAVE_CURRENT_DATA, it is possible for a
loadeddata event handler to actually run after the document load event
handler.

An obvious approach to avoid these surprises is to arrange for the state
changes to not be reflected in the element until the associated event
actually fires. That's a problem if you apply it generally, though. If you
delay changes to the 'currentTime' attribute until the associated timeupdate
event runs, either 'currentTime' does not reflect what is actually being
displayed or your video playback depends on timely JS event execution ---
both of those options are unacceptable. And allowing 'currentTime' to
advance while the readyState is still at HAVE_CURRENT_DATA seems like it
could be confusing too.

So I don't have a proposal here, just raising this issue and wondering if
anyone has any better ideas.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090410/d0abb798/attachment-0002.htm>