CaptureHandleChangeEvent should just be Event

[jan-ivar]

The doc says "Capturing applications who are permitted to observe a track's CaptureHandle have two ways of reading it."

This is one too many. The second way:

let handle;
track.oncapturehandlechange = event => handle = event.captureHandle();

...seems entirely redundant, since this should suffice:

let handle;
track.oncapturehandlechange = ({target}) => handle = target.getCaptureHandle();

I believe the common pattern in situations like this is to just fire a vanilla Event.

[eladalon1983]

I think that am reading between the lines that you want getCaptureHandle() to return the value set by the latest event. I'll clarify what I mean, then ask if I am reading correctly.

Clarification:

• Assume capturing_tab and captured_tab.
• Navigate captured_tab twice between different capture-handle-setting top-level documents.
• At least two events get fired in capturing_tab. (More, because of navigating away, but let's keep it simple.)
• When the document in capturing_tab calls getCaptureHandle(), it currently gets the latest value, regardless of what events are still pending on the queue.

Between the lines, I am reading that you want this to change, so that getCaptureHandle() would always return the value corresponding to the latest event that was popped off of the queue.

1. Did I read correctly?
2. If so - is this wise?

[eladalon1983]

Friendly ping @jan-ivar.

[jan-ivar]

See https://github.com/w3c/mediacapture-handle/issues/56.

... events are still pending on the queue.

JS state updates should be on the same queue, so there's no "latest value" confusion.

[eladalon1983]

Let's examine a scenario:

• C (capturer) is capturing T (target).
• T had long ago set a capture handle H0. C read it. Everything is static for a long time; maybe an hour.
• The clock strikes midnight, for dramatic effect as well as to simplify timestamps. It's now 00:00:00.
• At 00:00:01, T is navigated to a new document. Event E1 is fired on C to clear out the capture-handle.
• At 00:00:02, or one second later, the new document finishes loading and executes a call to setCaptureHandleConfig(). Event E2 is fired on C to set the new * capture-handle, H2.
• C's main loop was a bit busy around midnight and only handles E1 at 00:00:04 and E2 at 00:00:06. It actually ignores both events. But in between handling E1 and * E2 on the queue, at what happens to be 00:00:05, it decides to read the capture-handle through track.getCaptureHandle().

The question boils down to - does it make sense for a browser to give C the capture-handle from 4 seconds ago, rather than the current one?

[jan-ivar]

We don't have to ask this question for every new API. This has been solved many times, so we follow established patterns:

const transceiver = new RTCPeerConnection().addTransceiver("video");
transceiver.transport.onstatechange = () => console.log(transceiver.transport.state); // logs all states

The state getter returns "the value of the [[DtlsTransportState]] slot", which is set in the same queued task #56 that fires (synchronously calls) the statechange event (handler), "when the underlying DTLS transport needs to update".

It does not return any underlying "current" value. This is to preserve run-to-completion semantics.

[eladalon1983]

We don't have to ask this question for every new API.

I have not observed this discussion before. You have the benefit here of having been involved with more APIs than me. I'll do my best to catch up.

that fires (synchronously calls) the statechange event

This is the key part that I was overlooking - that events don't go in a queue (even if they can be called from a queued task).

Shall we close this issue and continue on #56?

[jan-ivar]

Why don't we keep this one open to track removing the custom event, and leave the other one to specify the event firing algorithms?

[eladalon1983]

That works for me.