Specify event handling with algorithms

[jan-ivar]

"The user agent fires an event" is under-specified, in ways that raises questions around timing.

Event handling is tricky and requires algorithms, since JS isn't allowed to observe things progressing in background processes naturally. For external occurrences, I recommend what WebRTC uses (as a minimum):

• When something happens, the user agent MUST queue a task that runs the following steps:
  • Check state, and abort these steps if unnecessary
  • Update JS-observable state
  • Fire an event named foo at target.
  • Don't do anything after this (to avoid UAFs)

This makes it easy to abide by the following design rule: "Where possible, use a plain Event with a specified type, and capture any state information in the target object." — because state is updated on the same task the event fires on (event dispatch is synchronous).

[eladalon1983]

The eureka moment for me is the realization that there is no queue of events, but rather, events can be fired either directly or from a queued task, but do not otherwise form a queue. Thank you @jan-ivar for bring it up, and thank you @alvestrand for clarifying.

With that in mind:

• Yes, let's go for a vanilla event.
• I think we should fire the event synchronously, and not from a queued task. This would make it easy to guarantee that track.getCaptureHandle() always returns the value associated with the latest event.

[jan-ivar]

For a user agent to trigger anything JS-observable, we must start from "When something happens, the user agent MUST queue a task" as I show above, to preserve run-to-completion semantics.

The "Update JS-observable state" step would be to set a [[CaptureHandle]] internal slot to its new value. We'd then update the getCaptureHandle method to simply return[[CaptureHandle]].

See "When the underlying DTLS transport needs to update the state" for an example.

[beaufortfrancois]

I'm leaving this comment there as well to not keep track of it.

the user agent MUST queue a task to fire an event with the name "capturehandlechange" at track.

_Originally posted by @beaufortfrancois in https://github.com/w3c/mediacapture-handle/pull/57#discussion_r864659868_