Re: play() sometimes doesn't do anything now that load() is async

On Tue, 13 Jan 2009, Simon Pieters wrote:
> 
> This is related to http://www.w3.org/Bugs/Public/show_bug.cgi?id=6353
> 
> Consider the following:
> 
>   <video id=v><script>
>    v = document.getElementById('v');
>    v.src = 'test';
>    v.play();
>   </script>
> 
> When the video start tag is parsed, load() is implicitly invoked and when the
> method returns (meaning scripts can potentially run before the next steps in
> load() are run, AIUI) networkState is NETWORK_LOADING.

I've changed this now. The load algorithm (a new concept) is invoked, but 
since neither src="" nor <source> are provided, it'll wait at this point.


> When setting the src attribute, load() will not be implicitly invoked again
> because networkState is not NETWORK_EMPTY.

At this point, the algorithm will resume, and will use the src="" 
attribute.


> When play() is invoked, load() will still not be implicitly invoked 
> again because networkState is not NETWORK_EMPTY.

The play() method will at this point now set /paused/ to false and fire 
'waiting'.


> So the list of candidates will be empty and nothing will play. This is 
> not what one would expect. (If you do an explicit load() before play() 
> it works as expected.)

I've also removed the list of candidates, because I noticed that as 
written the <source> elements would never actually get used. Instead, the 
algorithm just keeps track of where it is, and if it gets to the end of 
the list, it waits until more <source> elements come.


> We haven't found a nice way to fix this, yet. Maybe play() should be 
> async and set a flag that some step at the end of the load() algorithm 
> will look at and, if set, start to play the resource, or something.

The "paused" attribute is that flag.


On Tue, 13 Jan 2009, Dave Singer wrote:
> 
> We suggested a while back that there should be two state booleans
> play_requested
> play_in_progress
> 
> instead of the one today (which is "paused"), which I think would cover this
> case as well as:
> * stalls in download or streaming, which today are only noticeable if you
> catch the 'waiting" event (there's no state change)

What is the use case for the state? It seems like all you'd ever do here 
is show a little UI busy indicator, for which the events work. A state 
indicator seems like it'd encourage polling behaviour.


> * streaming protocols, which always lag between request and play (in 
> download, this only happens if you ask for play before the stack has got 
> far enough down the loading path)

Ideally, the user agent should buffer material Tivo-like, so that even 
with streaming protocols there is always data available. However, even if 
there isn't, this just simplifies to the same case as when the download 
hasn't progressed far enough yet.


On Thu, 15 Jan 2009, Philip Jägenstedt wrote:
> 
> Another option would be to have a current state and a pending state, 
> like several media frameworks do. The state enumeration could be NONE, 
> PAUSED, PLAYING and one could have two state variables currentState and 
> pendingState. The NONE state would be needed for pendingState when there 
> isn't actually a state transition in progress and as the initial value 
> for currentState before the resource has loaded and paused/played. The 
> paused attribute would of course no longer be needed.

This seems equivalent to what Dave suggested.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'