- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Jun 2023 14:18:41 +0000
- To: public-webrtc-logs@w3.org
> 1. Users may pick the wrong surface. My understanding is that a positive preference (prefer window, prefer tab) will often be sufficient. We talked about this in the past, maybe we should revisit this? That [discussion](https://github.com/w3c/mediacapture-screen-share/issues/1846) was concluded and the [PR](https://github.com/w3c/mediacapture-screen-share/pull/186) was merged. I don't think a positive preference for window indicates anything about willingness to also accept a monitor. I think we need a clear signal to exclude monitors, independent of other preferences. > 2. Users may dynamically switch to the wrong surface. Autopause is probably sufficient here? Why put obstacles in the users' path, by offering them an option that will be rejected by the Web application? Note that many users do not clearly distinguish the (a) Web application, (b) browser and (c) operating system. It's better when all work in concert on behalf of the user. > At least on macOS, the OS is more and more in charge of the sharing UX. This is good since it means there will be the same UX whether using a native app or a web page. Without a mechanism by which an app could relay its preferences to the operating system **through the browser**, none of the changes made by macOS will... * ...protect the user from the pitfall of choosing a source which the app will reject. * ...protect companies from leakage of private information through employee-error. > But this is relatively new territory. In general, it is easier/safer for us to design the right APIs once OS support is ironed out. Future OS APIs notwithstanding, there are the current macOS, Windows and Linux APIs, and the proposed preference would help with all of them. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/261#issuecomment-1611502224 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 June 2023 14:18:42 UTC