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

[Philip Jägenstedt]

On Mon, 16 May 2011 17:59:43 +0200, Remy Sharp <remy at leftlogic.com> wrote:

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

If we fail to come up with a better solution, then warning about the issue  
in big, bold, red letters is the least the spec should do, yes.

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

I already did: https://github.com/remy/html5demos/issues/12

Or do you mean a spec bug?

-- 
Philip Jägenstedt
Core Developer
Opera Software