- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 10 Jun 2015 11:46:02 +0200
- To: Njaal Borch <njaal.borch@norut.no>, Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
- CC: Francois Daoust <fd@w3.org>, public-webtiming@w3.org
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.
> 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.
Dom
Received on Wednesday, 10 June 2015 09:46:19 UTC