This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24353 - Possible race between <video> loadstart and window.onload
Summary: Possible race between <video> loadstart and window.onload
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-22 08:16 UTC by contributor
Modified: 2014-01-29 10:48 UTC (History)
4 users (show)

See Also:


Attachments

Description contributor 2014-01-22 08:16:14 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#loading-the-media-resource
Complete: http://www.whatwg.org/c#loading-the-media-resource
Referrer: 

Comment:
Possible race between <video> loadstart and window.onload

Posted from: 212.247.211.200 by simonp@opera.com
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36 OPR/19.0.1326.39 (Edition Next)
Comment 1 Simon Pieters 2014-01-22 08:34:26 UTC
Consider the following document

<!doctype html>
<script>
var v = document.createElement('video');
var s = document.createElement('source');
v.appendChild(s);
var events = [];
v.onloadstart = function(e) { events.push(e); }
onload = function(e) { events.push(e); }
</script>
<button onclick="alert(events)">check</button>

Interesting bits of RSA:

Step 3:
[[
Set the media element's delaying-the-load-event flag to true (this delays the load event).
]]

Step 8:
[[
⌛ Queue a task to fire a simple event named loadstart at the media element.
]]

This uses the media element event task source.

Step 9.20:
[[
⌛ Set the element's delaying-the-load-event flag to false. This stops delaying the load event.
]]

The End says at step 6:
[[
Spin the event loop until there is nothing that delays the load event in the Document.
]]

and step 7:
[[
Queue a task to run the following substeps:

...

If the Document is in a browsing context, create a trusted event named load ...
]]

This uses the DOM manipulation task source.

Now, it seems to me that it is possible that the video can reach step 9.20 before the loadstart task is run. The End can also be run before the loadstart task is run. In this case, nothing delays the load event, so The End doesn't spin the event loop. The End then queues the load event. Now we have two events on different task sources and it's not predictable which will fire first.

Possible fix is to queue a task using the DOM manipulation task source in RSA 9.20 to stop delaying the load event.

Same for RSA 9.6.6 for the src steps I think.
Comment 2 Ian 'Hixie' Hickson 2014-01-28 23:50:20 UTC
Ok I don't know if this fixes all the cases, but it should fix the ones above, at least; let me know if you see anything wrong:
Comment 3 contributor 2014-01-28 23:50:29 UTC
Checked in as WHATWG revision r8434.
Check-in comment: Try to reduce race conditions involving media elements and the 'load' event.
http://html5.org/tools/web-apps-tracker?from=8433&to=8434
Comment 4 Simon Pieters 2014-01-29 10:48:49 UTC
LGTM