- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 07 Jul 2023 14:02:30 +0000
- To: public-webrtc-logs@w3.org
> They will probably not do if browsers shipping this property first forbid users to select screen (instead of preventing users). Could you please explain the distinction between "forbid" and "prevent" in this context? > I still prefer we positively let websites express their interests, by telling they are interested in 'window, tab', which means no interest in screen. That API shape would mislead developers into expecting that they can influence the choice offered to the users beyond what they actually can. Assume valid options are `['browser', 'window', 'monitor']` and the developer specifies `['monitor']`. This is too risky; Chrome and Firefox[*] will ignore it and offer the user tabs and windows too. Won't developers find this surprising and start filing bugs? My experience with the Chromium bug tracker says yes... > If we are no longer talking about a hint We **are** most definitely talking about a **hint**, as in the case of the previous options we've introduced of the `"include"/"exclude"` shape, after which this is modelled. See for instance [selfBrowserSurface](https://www.w3.org/TR/screen-capture/#dom-displaymediastreamoptions-selfbrowsersurface), where the spec outright says: "The user agent MAY ignore this hint." --- [*] Or am I wrong, @jan-ivar? -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/261#issuecomment-1625464359 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 7 July 2023 14:02:31 UTC