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.<br clear="all">
<br>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.<br>
<br>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.<br>
<br>So I don't have a proposal here, just raising this issue and wondering if anyone has any better ideas.<br><br>Rob<br>-- <br>"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]<br>