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

Re: Specifying the association with an online timing service

From: Njaal Borch <njaal.borch@norut.no>
Date: Wed, 10 Jun 2015 12:00:16 +0200
Message-ID: <CAOc996u_bu-E5oBj6W1b3g9vyncj_1iJGKa_vT9EoB4ctA5hkg@mail.gmail.com>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>, Francois Daoust <fd@w3.org>, public-webtiming@w3.org
On 10 June 2015 at 11:46, Dominique Hazael-Massieux <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?

 I actually experience this kind of thing with the video.canplay event,
>> which on my typical machines on the current versions of browsers act
>> differently.  Chrome emits video.canplay on dektops (where it can play),
>> not on mobiles (which require a user event).  Firefox might emit
>> video.canplay, but is normally ready before I get to the point of
>> checking.  I therefore check if video.canplay, then create a new canplay
>> event and emit that, but that means often getting dupes on Chrome.  Very
>> annoying and unnecessarily complicated.
>>
>
> If you do
>   var v = document.getElementById('player');
>   v.addEventListener("canplay", function () { // ... });
> I think you should cover all the cases.
>

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.  I do tend to hook onto the video element
when the rest of my app is ready to run, which means that it could easily
be ready before I start actually playing anything.  It could of course be a
bug with FF, but if, as a general rule, emitted events are only emitted to
registered event handlers at the time, I would loose it if I was too slow
registering the event listener.

If providing the "currently valid event" on event listener add is the spec,
we're only talking bugs, otherwise chrome "works" by being slower than ff
is for video initialization!

N
Received on Wednesday, 10 June 2015 10:00:47 UTC

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