- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Sep 2022 00:04:38 +0000
- To: public-webrtc-logs@w3.org
Glad to hear support for the controller model! Totally agree that in absence of the controller a spec note seems fine. > It would be simpler if the controller is associated upon getDisplayMedia being called (except in case of synchronous exception). > In case focus() has been called before calling getDisplayMedia and getDisplayMedia fails, focus() should probably reject too with some kind of error. I like it. And synchronous exceptions aren't possible from async API methods, so we don't have to worry about those. > I am not a big fan of a timer here. ... 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. I feel we rabbit-holed in #190 and failed to find anything more restrictive that didn't trade one problem for another. But from some of the comments I worry I've undersold the model shift when a controller is present: The focus decision is untied from and no longer orchestrated by getDisplayMedia resolution. This gets us away from the microsecond timescale and questions of defaults. Instead, focus is explicitly executed by a separate `focus()` method where, much like a [transient activation-consuming API](https://html.spec.whatwg.org/multipage/interaction.html#activation-consuming-api), a relevant timescale of half-seconds seems fine, because what matters is the time between end-user action (hitting "Share" in the prompt) and when a window becoming focused will still be perceived as its reaction without it catching end-users off guard. Such decisions have traditionally been user agent ones. Defaults, settable states, and media output blocking seem a poor fit in this model. If we're to go with a method model then we should lean into its advantages of separation. Otherwise we should probably go with a different model. > controller.focus() is a bit unclear what is being focused In my mind, a captureController controls the capture so captureController.focus() focuses the capture, which seems clear to me, and I like short names, but we can always bikeshed. > It might make sense to allow UA to override the page asking not to focus. I think this would defeat use cases such as screen recording. My working assumption [as presented](https://docs.google.com/presentation/d/1ulgTHkHcpUa7FBtPHYYsUL1ATjO1meRmW5ghB9ELDXg/edit#slide=id.g12b1145f5f6_9_123) has been that screen-capture isn't solely a tool for video conference presentations, and that the current auto-focusing done by browsers amounts to a layer violation. Any perceived privacy guarantees from existing browser behavior here probably deserves to be challenged. I'm happy to beef up privacy indicator requirements, but we should probably discuss that in https://github.com/w3c/mediacapture-screen-share/issues/211 to avoid this getting long. > Do we really want to inform the capturer that the capturee has gained focus? ... privacy-concerns entailed? Privacy concerns seem no different to me from today where an app knows that if the resulting `displaySurface` is `"window"` or `“browser”` then the captured surface has been focused (or will be focused in ~1 second) 99% of the time in all browsers that support that surface type. I'm not sure what exploit is thwarted by the lack of accuracy that a promise would provide here. At the same time, I don't have a specific use case in mind, and agree it is not a requirement, so I'm open to discuss, but am curious about reasons to resolve the promise prematurely. The method model does offer us a way to convey failure to focus for whatever reason. Might that be of interest to video conferencing sites? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/230#issuecomment-1234927017 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 2 September 2022 00:04:40 UTC