W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

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

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 17 May 2011 13:52:10 -0400
Message-ID: <BANLkTik+n5AmjEgG9N7ZpzbN_33s1LZSbQ@mail.gmail.com>
On Tue, May 17, 2011 at 5:09 AM, Philip J?genstedt <philipj at opera.com>wrote:

> To target this specific pattern, one hypothetical solution would be to
> special-case the first script that attaches event handlers to a <video>
> element. After it has run, all events that were already fired before the
> script are fired again. However, this seems awfully messy if the script also
> observes readyState or networkState. It might also interfere with browsers
> that use scripts behind the scenes to implement the native controls.
>
> Although a kludge, another solution might be to block events from being
> fired until x more bytes of the document have been parsed


Masking the bug harder seems risky.  The problem would still exist, it would
just be a bit more obscure and even less understood.

or it has finished loading.
>

I imagine anything done here should be done for all load-related events,
like <img onload>.  It's probably not good to effectively disable
asynchronous load events for images.

These events could be split into two parts: one which is deferred until the
document is finished loading ("load", "canplay") and less obviously-named
ones which are fired normally ("asyncload", "asynccanplay"), which people
are unlikely to use without at least looking at documentation to know they
exist.  That would give a "safe", less-racy event by default, and give a
somewhat less obviously-named event for people who know what they're doing
and really don't want these events deferred.

That would regress performance for existing pages, though.

-- 
Glenn Maynard
Received on Tuesday, 17 May 2011 10:52:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:06 UTC