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

I have some API nits (and agree we shouldn't overload addEventListener). I'd prefer:
```js
const controller = new CaptureController();
controller.addEventListener("switch", ({stream}) => video.srcObject = stream);
controller.manualSwitching();
video.srcObject = await navigator.mediaDevices.getDisplayMedia({controller});
```
This is modeled on [messagePort.start()](https://developer.mozilla.org/en-US/docs/Web/API/MessagePort/start) which is _"only needed when using [EventTarget.addEventListener](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener); it is implied when using [onmessage](https://developer.mozilla.org/en-US/docs/Web/API/MessagePort/message_event)"_, which makes this equivalent:
```js
const controller = new CaptureController();
controller.onswitch = ({stream}) => video.srcObject = stream;
video.srcObject = await navigator.mediaDevices.getDisplayMedia({controller});
```
I.e. `manualSwitching()` is implicit with `onswitch`.

While I'm coming around on the API, I don't like the idea of limiting this existing and useful end-user feature only to sites that opt-in. That seems like a loss for users. Hence the name `manualSwitching()` instead of `enableDynamicSwitching()`.

I'd prefer if this new API came with language to encourage browsers to not gate the feature only on apps that opt-in to the _event_ model.

I have reservations about abandoning the old _injection_ model which had some unique advantages:
1. Works with all websites without needing their support (user benefits)
2. No need to replaceTrack downstream peer-connection sinks
3. No risk of ending a MediaRecorder sink recording prematurely
4. Difficult for apps to deny user switching (user benefits)

So I'm not convinced the _event_ model is always better just because it wins solving the most advanced case (the tightly integrated crop-enabled VC+SLIDE app). For VC apps that DON'T have integrated SLIDE apps, it's not clear why the event API is needed (apart from audio which I propose a solution for below).

When it comes to audio (which I see as the lone flaw in the injection model for _most_ VC sites), the following might work well enough in the injection model:
```js
const stream = await navigator.mediaDevices.getDisplayMedia({audio: true});
video.srcObject = stream;
stream.onaddtrack = ({track}) => console.log(`audio added`);
```
The UA could subsequently mute the audio track as needed rather than remove it. Thoughts?

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/255#issuecomment-1730586514 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 01:06:01 UTC