Queue a task to handle media session action

[jan-ivar]

Need a task to invoke the handle media session action on.

---

Preview | Diff

[youennf]

It is unclear what the exact model here is related to queuing a task.
In particular, if there are multiple actions that happen at the same time (muting a camera and a microphone for example), should there be two tasks involved or is it fine to execute the action handlers in the same task.

In particular, there is already in the spec:

The user agent MAY [queue a task](https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task) in order to run the [media session actions update algorithm](https://www.w3.org/TR/mediasession/#media-session-actions-update-algorithm) in order to avoid UI flickering when multiple actions are modified in the same event loop.

@steimelchrome, do you know what Chrome is doing in terms of implementation in that area?

[jan-ivar]

It is unclear what the exact model here is related to queuing a task.

Queuing a task here is necessary to preserve run-to-completion semantics.

Action handlers being event-like means: "You should always defer events if the algorithm that triggers the event could be running on a different thread or process. In this case, deferral ensures the events can be processed on the correct task in the task queue."

In particular, if there are multiple actions that happen at the same time (muting a camera and a microphone for example), should there be two tasks involved or is it fine to execute the action handlers in the same task.

AFAIK best practice is to queue a task for each event, keeping things nice and separate. Coalescing event firing into a single task creates all sorts of headaches, including (historically) sec bugs running c++ after JS.

The spec already seems to assume this to some extent, by specifically calling for special handling of "joint commands":

"When the user agent receives a joint command for play and pause, such as a headset button click,"

In particular, there is already in the spec:

The user agent MAY [queue a task](https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task) in order to run the [media session actions update algorithm](https://www.w3.org/TR/mediasession/#media-session-actions-update-algorithm) in order to avoid UI flickering when multiple actions are modified in the same event loop.

That language seems flawed as it assumes a mode where user agents do NOT need to queue a task to get on the event loop, and that this mode would somehow create "UI flickering". Last I checked, queuing a task does not "avoid UI flickering".

[steimelchrome]

It is unclear what the exact model here is related to queuing a task. In particular, if there are multiple actions that happen at the same time (muting a camera and a microphone for example), should there be two tasks involved or is it fine to execute the action handlers in the same task.

In particular, there is already in the spec:

The user agent MAY [queue a task](https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task) in order to run the [media session actions update algorithm](https://www.w3.org/TR/mediasession/#media-session-actions-update-algorithm) in order to avoid UI flickering when multiple actions are modified in the same event loop.

@steimelchrome, do you know what Chrome is doing in terms of implementation in that area?

If I'm reading the code correctly, we're currently queueing a task per action, and they're all on the same task source (MiscPlatformAPI for now, though we'd move to the UserInteraction source for this change). I don't think there's any way for us to run two actions simultaneously