[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 #19 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-04-27 23:39:04 UTC ---
(In reply to comment #17)
> (In reply to comment #15)
> > As a developer I just know that when I take a peek at the readyState, it will
> > be merely more than a Heisenberg measurement.
> 
> I think you meant "as the author of The Definitive Guide to HTML5 Video" ;-)

I've also developed Websites that use HTML5 video, so I claim I also have a
right to call myself a Web developer. :-) But indeed, I have come across
inconsistencies between browsers when asking for the readyState value at
certain points in JavaScript.


> It's enough that 1% of web authors make a mistake and create scripts with race
> conditions for this to be a serious problem, causing browsers with slightly
> different timing to appear more broken than the ones that were tested.

I'm happy if we can reduce the problem that different browsers are in different
states when you probe them "at the same time", e.g. right after calling an
event.

However, I have found the best approach is to discourage Web developers from
using readyState on video. I've never needed to use it in any of my
applications - there wasn't anything that I couldn't solve with events.

I am also shocked when I see people recommend the use of readyState for things
where the event would be completely appropriate, such as in this stackoverflow
bug
http://stackoverflow.com/questions/2221029/problem-retrieving-html5-video-duration
where the recommended solution uses readyState with a setInterval.

I feel very compelled to actually ask for removal of readyState, since it is
causing more harm than it helps IM-NSH-O.

> > I am struggling to see the race conditions that are being used as a reason to
> > make changes to state transitions here. Can you provide an example where the
> > developer would get the wrong information? Or would get into an unsolvable
> > situation?
> 
> It's almost always possible to work around the race conditions if you know
> they're there. I listed some examples of problems that less-than-perfect
> programmers could run into in
> <http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0232.html>.

I do agree that some things are underspecified.

Such as what is supposed to be the result of these actions that you listed:

* When removing the autoplay attribute in any of the loadstart,  
loadedmetadata, loadeddata or canplay event handlers, it's racy whether or  
not the media element will actually play.

* When registering a loadeddata event handler in the loadedmetadata event  
handler, it's racy whether or not that event handler will run. The same is  
true of any other pair of events that depend on readyState or networkState  
transitions. Having this not be racy would be useful when writing tests,  
e.g. to catch the first canplaythrough event after the seeked event.

* When currentTime is set in the loadstart event handler, it's racy  
whether or not it will actually seek.

The behaviour of browsers in these situations needs to be deterministic and so
it probably needs to go into the spec. If freezing the changes on readyState
and networkState to event changes helps achieve this, then this is good. We
have to decouple the IDL attribute readyState from the browser-internal state
machine of the media engine. I actually see this as a good thing since the Web
developer really doesn't need to know internal states, but only needs to know
when it is safe to do certain things.


As for this problem:

* For preload=metadata, when checking networkState in a progress event  
handler, it's racy between NETWORK_LOADING and NETWORK_IDLE. This makes it  
impossible to test if we follow the spec on fast networks.

The readyState and networkState are indeed much more part of the
as-yet-to-be-developed statistics API than they are useful for basing script
behaviour on.

-- 
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 Wednesday, 27 April 2011 23:39:09 UTC