- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 01 Sep 2022 07:08:56 +0000
- To: public-webrtc-logs@w3.org
> The controller is associated 1 ←→ 1 upon getDisplayMedia success, and cannot be re-associated after that. I do not see much value in reusing controller objects. It would be simpler if the controller is associated upon getDisplayMedia being called (except in case of synchronous exception). That would cover the case of getDisplayMedia being called twice in a row for instance. First one would proceed, second one would reject synchronously. > 1\. Presence of the controller suppresses the automatic bring-to-front with focus that happens today. Seems fine given above caveat. > 2\. Without a controller, getDisplayMedia would bring-to-front with focus like today for backwards compatibility. This is UA territory, I am not sure the current spec says anything about this. A note in the spec would probably be good here. > 3\. Apps may call focus() anytime ahead of getDisplayMedia or right after it (upto 1 second after seems fine, but let’s iterate on details) I am not a big fan of a timer here. First we might enter UA territory, with different timeout values. Second, if you leave something like 1 second, people might want to go to network (say with Capture Handle identity) to decide what to do. This might lead to races between the timer and networking. Maybe we should start with something restrictive and relax to a timer approach if we see good use cases for it. Or we could require an explicit decision from the capturer and delay video frame delivery until the decision is made. focus() would then take a boolean parameter to express the decision of the capturer. We would delay delivery of video frames until the focus promise is settled. > 4\. focus() resolves after the captured window or tab has been brought to front and focused, or asap for monitor display surfaces, but no earlier than gDM success. This seems fine. That means getDisplayMedia promise resolves first, then focus promise. In case focus() has been called before calling getDisplayMedia and getDisplayMedia fails, focus() should probably reject too with some kind of error. This aligns with the idea to associate controller and getDisplayMedia request at getDisplayMedia call time. Some additional thoughts: * controller.focus() is a bit unclear what is being focused, capturee or capturer. Any idea how to make the name clearer? * It might make sense to allow UA to override the page asking not to focus. This is probably important to state something like this given this is observable to JS. focus could reject with an error of type NotAllowedError for instance. * In case UA implements a dynamic "change the surface" picker, should there be a possibility for the web application to decide again whether focus happens? -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/230#issuecomment-1233841051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 1 September 2022 07:08:58 UTC