[whatwg] <video> ... <script> race condition

[Remy Sharp]

Hi all,

Since this is *my* code that we're talking specifically about, I'd like to repeat Glenn's point that this is not sloppy code (the cheeky shit), and that the /everyman/ developer is going to think that attaching an event is perfectly legal and will expect it to work.

Now you're right, whoever pointed out the 7am alarm example, if you attach the event too late, then you'll miss the boat.  However, it's a chicken an egg situation.  You don't have the DOM so you can't attach the event handler, and if you do have the DOM, the damn event has fired already.

What's the fix?  Well, the work arounds are certainly viable, again from an everyman developer point of view:

1) Attach higher up, on the window object and listen for the canplay/loadedmetadata/etc and check the event.target
2) Attach an inline event handler (not nice, but will do)

The fix?  Since ultimately we have exactly the same potential "bug" with image load events, is to update the specification and make it clear: that depending on the speed of the connection and decoding, the following "xyz" events can fire **before** your script runs.  Therefore, here's a couple of work arounds - or just be aware.

Any objections?  At the same time, does someone want to raise this as a bug?

Cheers folks,

Remy Sharp / everyman developer :)

On 16 May 2011, at 08:20, Simon Pieters wrote:

> On Sun, 15 May 2011 19:11:09 +0200, Glenn Maynard <glenn at zewt.org> wrote:
> 
>> On Sat, May 14, 2011 at 11:49 AM, Eric Carlson <eric.carlson at apple.com>wrote:
>> 
>>> It seems to me that the right way to "fix" the problem is let people know
>>> it is sloppy code, not to figure out a way to work around it.
>>> 
>> 
>> The basic problem is that it isn't sloppy code: it's correct for almost all
>> events.  It's just wrong for events that are fired as part of loading, which
>> is what makes it so easy to get wrong.  It also means that these events
>> don't work well with deferred scripts.
>> 
>> For the simple cases I'd probably do:
>> 
>> video.addEventListener("canplay", func, false);
>> if(video.readyState >= HAVE_FUTURE_DATA)
>>    func.apply(video); // missed the first one
> 
> The state can have changed before the event has actually fired, since state changes are sync but the events are queued. So if the script happens to run in between then func is run twice. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267
> 
> -- 
> Simon Pieters
> Opera Software