- From: Dave Singer <singer@apple.com>
- Date: Tue, 13 Jan 2009 12:57:05 -0800
- To: Simon Pieters <simonp@opera.com>, public-html <public-html@w3.org>
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 -- David Singer Multimedia Standards, Apple Inc.
Received on Tuesday, 13 January 2009 20:58:14 UTC