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

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.

Philip

On Tue, 13 Jan 2009 21:57:05 +0100, Dave Singer <singer@apple.com> 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)
> * 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)
>
> clearly !play_requested && play_in_progress should never occur, but the  
> other three conditions can.
>
>
>
> At 16:20  +0100 13/01/09, 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.
>>
>> When setting the src attribute, load() will not be implicitly invoked  
>> again because networkState is not NETWORK_EMPTY.
>>
>> When play() is invoked, load() will still not be implicitly invoked  
>> again because networkState is not NETWORK_EMPTY.
>>
>> 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.)
>>
>>
>> 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.
>>
>> --
>> Simon Pieters
>> Opera Software
>
>



-- 
Philip Jägenstedt
Opera Software

Received on Thursday, 15 January 2009 08:44:47 UTC