W3C home > Mailing lists > Public > public-webtiming@w3.org > June 2015

Re: Specifying the association with an online timing service

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 10 Jun 2015 14:05:19 +0200
Message-ID: <557827FF.3060605@w3.org>
To: Njaal Borch <njaal.borch@norut.no>
CC: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>, Francois Daoust <fd@w3.org>, public-webtiming@w3.org
On 10/06/2015 12:53, Njaal Borch wrote:
>
> The attached test does work, as it hooks everything up before the video
> element becomes ready.

Right; this is what I was illustrating — code sequenced in a single 
execution task can't have underlying state changed under its feet.

> Try adding a setTimeout around it, like:

Right; but setTimeout precisely creates a separate execution stack, in 
which case the JavaScript semantics I was alluded to no longer apply (by 
design, otherwise asynchronous code would be useless).

>        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. :-)

One you switch to an asynchronous mode of execution, you can't (and thus 
shouldn't) make any assumption about the order and timing of async 
operations.

Dom
Received on Wednesday, 10 June 2015 12:05:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC