[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 #20 from Philip Jägenstedt <philipj@opera.com> 2011-04-28 08:26:14 UTC ---
(In reply to comment #19)
> (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.

Sure, my point was only that you know a lot more than most about the
idiosyncrasies of <audio> and <video>.

> > 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 absolutely agree, but not everyone will take the advice.

> 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 voted against the accepted answer :) That's just the way the web works,
people try "random" permutations of scripts and markup until it works. That's
why we can be 100% sure that any race conditions in the platform will
eventually be exposed.

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

I would be tentatively supportive, if you file a bug we can see if the idea is
shot down or not. It would break some existing content, that's for sure.

> > > 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.

Indeed, what I've implemented now is a kind of filtering state machine that has
an actual state and a script-seen state. Ugly, but better than
unreliable/untestable behavior.

> 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.

I'm not sure either will ever be truly useful, but I'm glad to see you're an
optimist :)

-- 
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 Thursday, 28 April 2011 08:26:18 UTC