Bug 203667 – Integrate media code to use HTML5 event loop

• Component: Media
• Status: RESOLVED CONFIGURATION CHANGED

[Ryosuke Niwa]

WindowEventLoop and WorkerEventLoop has the nice property to preserve the order of events
even when the documents go into a page cache.

Make media code use WindowEventLoop instead of GenericEventQueue.

This will also allow us to avoid triggering idle callback while there is a pending media events.

[Ryosuke Niwa]

Created attachment 382438 [details]
WIP

[Ryosuke Niwa]

Comment on attachment 382438 [details]
WIP

View in context: https://bugs.webkit.org/attachment.cgi?id=382438&action=review

> Source/WebCore/html/track/TrackListBase.cpp:103
> +    m_element->document().eventLoop().queueTaskToDispatchEvent(TaskSource::MediaElementEventTaskSource, *this,

This is a bit verbose. I think we can add a helper function on ActiveDOMObject so that we can call it like this:
queueTaskToDispatchEventOnThis(TaskSource::MediaElementEventTaskSource,
    TrackEvent::create(eventName, Event::CanBubble::No, Event::IsCancelable::No, WTFMove(track)));

[Ryosuke Niwa]

Created attachment 382539 [details]
WIP2

[Radar WebKit Bug Importer]

<rdar://problem/56891008>

[Geoffrey Garen]

Comment on attachment 382539 [details]
WIP2

View in context: https://bugs.webkit.org/attachment.cgi?id=382539&action=review

> Source/WebCore/dom/ActiveDOMObject.h:122
> +    void queueTaskToDispatchEventOnThis(EventTargetType& target, TaskSource source, Ref<EventType>&& event,

No need to say "OnThis", since you pass the target explicitly.

[Ryosuke Niwa]

(In reply to Geoffrey Garen from comment #5)
> Comment on attachment 382539 [details]
> WIP2
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=382539&action=review
> 
> > Source/WebCore/dom/ActiveDOMObject.h:122
> > +    void queueTaskToDispatchEventOnThis(EventTargetType& target, TaskSource source, Ref<EventType>&& event,
> 
> No need to say "OnThis", since you pass the target explicitly.

Oh yeah, that suffix got removed.

[Ryosuke Niwa]

Created attachment 383116 [details]
WIP3

A few observations:
 * Media elements can move from one document to another so we need to support event loop's task changing its associated script execution context (otherwise media/adopt-node-crash.html would crash)
 * We need to make DeferrableTask work with EventLoop.
 * We need a way of grouping tasks together so that we can later cancel them all, or check if there is a pending task in the same group or not.

[Ryosuke Niwa]

I've started to think that we may want to make "EventLoopGroup" which can be suspended or stopped, which is implemented by ScriptExecutionContext.

This way, the mechanism by which a group of tasks are suspended or stopped is shared between script execution context & other kinds of grouping.

One complication is that we'd have to support a task moving from one group to another (so that media elements that move from one document to another would belong to the right group after the move).

[Ryosuke Niwa]

(In reply to Ryosuke Niwa from comment #8)
> I've started to think that we may want to make "EventLoopGroup" which can be
> suspended or stopped, which is implemented by ScriptExecutionContext.
> 
> This way, the mechanism by which a group of tasks are suspended or stopped
> is shared between script execution context & other kinds of grouping.
> 
> One complication is that we'd have to support a task moving from one group
> to another (so that media elements that move from one document to another
> would belong to the right group after the move).

What's interesting about this approach is that this will allow us to merge WorkerEventLoop and WindowEventLoop implementations as well; because in this world, what suspends, resumes, or stops will be a EventLoopGroup, not ScriptExecutionContext.

[Ryosuke Niwa]

Created attachment 383205 [details]
WIP4

[Ryosuke Niwa]

Created attachment 383206 [details]
WIP5

[Ryosuke Niwa]

Chris has done this already.