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 18570 - The media element event task source should probably be ditched and the DOM manipulation task source be used instead. Having some media events have undefined order compared to other tasks is just asking for trouble. (http://www.whatwg.org/specs/web-apps/cu
Summary: The media element event task source should probably be ditched and the DOM ma...
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: 19853
  Show dependency tree / graph
 
Reported: 2012-08-15 08:02 UTC by contributor
Modified: 2013-03-08 19:47 UTC (History)
5 users (show)

See Also:

Attachments

Description contributor 2012-08-15 08:02:34 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html
Multipage: http://www.whatwg.org/C#media-element-event-task-source
Complete: http://www.whatwg.org/c#media-element-event-task-source

Comment:
The media element event task source should probably be ditched and the DOM
manipulation task source be used instead. Having some media events have
undefined order compared to other tasks is just asking for trouble.
(http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element
.html#audiotracklist-and-videotracklist-objects already uses DOM task source)

Posted from: 94.234.170.58 by simonp@opera.com
User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.289 Version/12.01
Comment 1 Ian 'Hixie' Hickson 2012-08-27 02:02:56 UTC 
Can you give an example of two events that are on different task sources that could be theoretically ordered?
Comment 2 Simon Pieters 2012-08-27 07:02:38 UTC 
<video> error
window load
Comment 3 Ian 'Hixie' Hickson 2012-10-31 23:13:50 UTC 
Ok, I've made the 'error' event that delays the load event be on the DOM manipulation task source.

Any others?
Comment 4 contributor 2012-10-31 23:14:34 UTC 
Checked in as WHATWG revision r7494.
Check-in comment: Prevent a race condition between <video onerror> and <body onload>
http://html5.org/tools/web-apps-tracker?from=7493&to=7494
Comment 5 Simon Pieters 2012-11-02 09:35:40 UTC 
Hunting through the spec for race conditions between different events is a lot of work. At this point I would instead like to ask what problem the media element task source is intended to solve.
Comment 6 Ian 'Hixie' Hickson 2012-11-02 21:21:17 UTC 
It's intended to make it possible to implement the media aspects in another process, where you might not be able to synchronise things with DOM events.

As a general rule, a task source should only have things on it that all have a defined relative order. If there are two tasks on a task source that you couldn't prove were executed out of order, then there's no point having them on the same task source, as it's untestable. So for example, if you have two <video> elements, and they're both playing a video, you wouldn't be able to predict which will end first (since even a little bit of CPU contention could delay one but not the other, with no indication to the page), so there's no point having their events on the same task source.
Comment 7 Philip Jägenstedt 2012-11-05 12:21:41 UTC 
I don't understand why out-of-process or in-process media decoding really makes a difference here, as all the messages being sent from the media framework to the browser core are asynchronous anyway.
Comment 8 Ian 'Hixie' Hickson 2012-11-05 20:05:50 UTC 
Everything we're talking about here is asynchronous, the question is just whether the ordering can be guaranteed. For some of the events (e.g. 'error' vs 'load') we can guarantee it. For others (e.g. events regarding what media elements are ending when) we could guarantee it, but that would require close coordination between the different parts of the media framework, which would be difficult if you're reusing a framework (especially one in a different process).


Anyway, unless there's a specific concern, I think the remainder of this bug's request is WONTFIX on the grounds described above.
Comment 9 Simon Pieters 2012-11-06 13:32:12 UTC 
I think there are more cases where we can/should guarantee an order. For instance, 'suspend' in the preload=none case vs. window 'load' seems similar to 'error'. Searching for "delaying-the-load-event flag" in the spec gives an indication of cases where some event can be racy with window 'load'.
Comment 10 Ian 'Hixie' Hickson 2013-03-08 19:47:16 UTC 
Yeah, good call. I've done a more thorough sweep. Let me know if there's still more that I missed...

I still don't think the original request makes sense, because in most cases it would just hide that the relative order between two events is undefined, without actually defining it (and without making it testable). I'm much more comfortable having a separate task source for each actually-ordered group of tasks.
Comment 11 contributor 2013-03-08 19:47:37 UTC 
Checked in as WHATWG revision r7743.
Check-in comment: Try to make ordering of media events even more well-defined.
http://html5.org/tools/web-apps-tracker?from=7742&to=7743