Re: [mediacapture-screen-share] Auto-pause capture when user switches captured content (#255)

(answering multiple people)
>  I think enable... would make it clearer that it's a setter. So enableManualSwitching().

đź‘Ť

> ... developers may read controller.onswitch = ... and think they can/should use controller.addEventListener('switch', ... ... and realize eventually their code doesn't work without understand why at first glance.

Yes, this literally happened to me with web workers! So I sympathize, but I did figure it out, and there IS precedence here, which may help devs... This might come down to one's view of onfoo vs addEventListener("foo", ) ...

> as they've been educated to not use onfoo anymore 

Where is this advice? I recall it years back, but worry it may be outdated. See [§ 7.4. Always add event handler attributes](https://www.w3.org/TR/design-principles/#always-add-event-handlers).

IMHO `onfoo` is fine in top-level app code ("top-level" = the level owning the target). E.g. with
```js
const video = document.createElement('video');
video.srcObject = stream;
await new Promise(r => video.onloadedmetadata = r);
```
...there's no problem since `video` is not available outside this async function yet. Just avoid hiding it inside sub-functions and helper functions.

In this issue, I'm even hearing an argument for a _single_ callback which (I don't agree with but) I suspect means `controller.onswitch = f` would likely satisfy 99% of cases.


> ... allowing the registration of multiple event listeners seems like a footgun in itself.

I think it's generally agreed that _not_ allowing multiple listeners is the footgun. E.g. two areas (functions) of an app both set onfoo or setMy(callback) whatever, causing one to remove the other, a hard-to-debug [action at a distance](https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)).

Lots of precedence says multiple events are OK. See [§7.3. Don’t invent your own event listener-like infrastructure](https://w3ctag.github.io/design-principles/#dont-invent-event-like).

> > ```js
> > stream.onaddtrack
> > ```
> 
> I am not a big fan, given many websites do tend to recreate MediaStreams on the fly or clone them. In the future, we might want to transfer MediaStream as well.

Sure, but the same is true of the MediaStream(s) managed by RTCRtpReceiver. But I find it interesting that the video.srcObject sink [handles it seamlessly](https://jsfiddle.net/jib1/rnjztyo5/) in all browsers. But I agree real-world sinks would likely need to take some action, e.g. with the track-based RTCPeerConnection:
```js
stream.onaddtrack = pc.addTrack(track);
```

> The application would also need to stick to both CaptureController and the MediaStream for being notified of what is happening.

This API solves the audio problem in the injection case, which doesn't require CaptureController. The question here probably comes down to whether we want to solve the audio injection case or not...

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/255#issuecomment-1732030667 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 22 September 2023 21:04:00 UTC