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.4.0 : Wednesday, 22 January 2020 16:59:33 UTC