- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Feb 2022 13:58:16 +0000
- To: public-webrtc-logs@w3.org
> The comment dismisses the 'reject screen' position as if there is no other ground than purity. The discussion has taken place over many threads, comments, editors' meetings and WG interim meetings. I remember a strong objection to "MAY reject" in favor of "MUST reject." I remember but one reason, and I have addressed it. If my recollection is faulty, I welcome correction. > Given there seems to be solutions that Chrome used successfully in the past (needs validation from your side), and given you expressed interest in fixing those issues, I am thinking we have a path forward. Wdyt? I think events will unfold as follows, if we merge a PR that says "MUST reject monitor": 1. We merge the PR. 2. Chrome implements it verbatim, but retains the default behavior of screens-first when no ideal surface is specified. 3. Chrome introduces changes in a certain Chrome version that simultaneously (i) change the default behavior to tabs-first but also (ii) allow `ideal: 'monitor'` to trigger the old behavior. Part (ii) is intended to be a temporary off-ramp. And here the path diverges. * If there is no loud opposition, the off-ramp is dismantled and 'monitor' is removed. Everybody is happy (me, WG, Chrome Security, Chrome Privacy). * If there is sufficiently loud opposition, the off-ramp becomes a permanent fixture, in direct violation of the spec. The second possibility would be less painful if we just s/MUST/MAY. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1026871438 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 February 2022 13:58:18 UTC