Re: [mediacapture-screen-share] Conditional Focus (When Display-Capture Starts) (#190)

> > The browser can operate in modes which skip the prompt.
> 
> That is out of scope for this working group.

I have foreseen this response and added the text which you quoted immediately below (agnosticism etc.). The topic is not whether we can handle it spec-wise, but rather whether it produces ergonomic results for the application. Consider:

```js
const stream1 = await navigator.mediaDevices.getDisplayMedia();
const [track1] = stream.getVideoTracks();
doSomething();  // Maybe ends the task, mabye doesn't.
navigator.mediaDevices.focusPolicy = "no-focus"; // Handle focus - or not.
doSomethingElse();  // Same thing.
const stream2 = await navigator.mediaDevices.getDisplayMedia();
const [track2] = stream.getVideoTracks();
```

The global-attribute API produces code which is hard to reason about. Does it affect `track1`? Does it affect `track2`? Both? Neither? If flaky for either - what is the bug? It's definitely not simple.

> Not a problem. JS is single-threaded,

My assertion is **not** that it's impossible to spec this properly. I argue that the result is not ergonomic and not simple.

> Also, if ergonomics is the issue, why isn't it `stream.focus()`?

Well, if you think ergonomics would be improved by moving `focus()` to `MediaStream`, we can discuss. My motivation for **not** putting it there was that MediaStreams can get tracks added/removed, and then `focus()` becomes... un-simple.

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


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

Received on Monday, 27 September 2021 17:24:34 UTC