Re: Specifying the association with an online timing service

The attached test does work, as it hooks everything up before the video
element becomes ready.
Try adding a setTimeout around it, like:
      setTimeout(function() {
      var v = document.getElementById('v');
      v.addEventListener('canplay', function() {
        document.getElementById('log').textContent = 'ready to play';
      });
    }, 1000);

Actually, with just 100ms delay, my FF often does not emit the event, one
second delay and it never does.  Chrome mostly emits it with 1s delay,
never with 2s...  FF is particularly faster on reloads, clearly caching
some data. So if you want to get the event consistently, you will have to
register for the canplay listener early enough.  There are of course
solutions (be faster, do the check and emit yourself), but we can do this
consistently by replaying the event on addEventListener. :-)

N


---
Dr. Njål Borch
Senior researcher
Norut Tromsø, Norway

On 10 June 2015 at 12:05, Dominique Hazael-Massieux <dom@w3.org> wrote:

> On 10/06/2015 12:00, Njaal Borch wrote:
>
>> On 10 June 2015 at 11:46, Dominique Hazael-Massieux <dom@w3.org
>> <mailto:dom@w3.org>> wrote:
>>
>>     On 10/06/2015 08:32, Njaal Borch wrote:
>>
>>         there's even the rather horrible race condition in all the
>> two-step
>>         versions:
>>
>>         if somestate execute func1;
>>                                     <---  somestate changes
>>         somestate.on("change", func1);
>>
>>
>>     I don't think that ("somestate changes") can happen within the
>>     semantics of JavaScript — i.e. no state can be changed "in the
>>     background" beore the current function stack is fully run through.
>>
>>
>> Can not somestate change if that is for example the readiness of a video
>> element?  Presumably things can happen in the browser in parallel even
>> if the JS engine does not?
>>
>
> Nope (or rather, that change is not reflected to the engine until the
> current stack is done).
>
>
>> You'd think so, right?  I'm not sure why FF doesn't actually do this,
>> but I was assuming it to be because "canplay" has gone from false to
>> true before I register the event listener.
>>
>
> It doesn't behave this way for me - the attached test run in Firefox
> displays "ready to play" as expected.
>
> Dom
>