Elad Alon

(Btw, I am not sure what urgency is discussed in [this comment](https://github.com/w3c/mediacapture-screen-share/issues/230#issuecomment-1235888289). The entire premise of Conditional Focus is that the captured surface may be focused or not focused depending...

> Would this unspecified behavior be identical to point 1? Unspecified is unspecified, but at least in Chrome's implementation, yes, that's what I intend. > people might add the controller...

> The use cases I heard so far: Youenn, the very first post of the [original thread](https://github.com/w3c/mediacapture-screen-share/issues/190) mentions the need for **conditionally** focusing depending on what application is being captured....

> So the urgent use case you have in mind is web app focus decision based on information provided by capture handle identity? Correct. This has been presented in the...

@jan-ivar, if, [as you propose](https://github.com/w3c/mediacapture-screen-share/issues/230#issuecomment-1235982999), we specify that both getDisplayMedia() and getDisplayMedia({controller}) must have the same default unspecified behavior in the absence of a call to setFocusBehavior(), then it will...

> Rejecting the promise is probably better. We can do the following if you'd like: * Timer in the content process elapses -> reject the promise. * Timer in the...

> Why is it important to silent fail this case? It seems better to report the error. Because we want `setFocusBehavior()` to be sync. Or do you see this case...

I think it's counterproductive to force a user to share their (screen AND system audio) when they only want to share (system audio). Similarly for sharing (tab pixels AND tab...

The question of use-cases is interesting and I'll get back to that. Quick recap first of the benefits of supporting audio-only, assuming use-cases exist: * Benefit to the user: *...

> The decision to reject can be done today based on a timer. Yes, that's my thinking. > The only thing is when the promise gets actually settled: either after...