W3C home > Mailing lists > Public > public-html@w3.org > January 2009

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

From: Dave Singer <singer@apple.com>
Date: Tue, 13 Jan 2009 12:57:05 -0800
Message-Id: <p0624085ac592b0037d09@[]>
To: Simon Pieters <simonp@opera.com>, public-html <public-html@w3.org>

We suggested a while back that there should be two state booleans

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 
>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 
>Simon Pieters
>Opera Software

David Singer
Multimedia Standards, Apple Inc.
Received on Tuesday, 13 January 2009 20:58:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:41 UTC