- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Feb 2022 11:35:04 +0000
- To: public-webrtc-logs@w3.org
> The reality is that Chrome rolls back changes that prove overly unpopular.
This is fine. If browsers cannot ship something, specs should be aligned.
If some browsers are able to ship it but not others, we need to discuss what to do.
> colleagues of mine have run into such [issues](https://bugs.chromium.org/p/chromium/issues/detail?id=1286760) when aligning Chrome implementation with the spec with respect to making `getUserMedia` wait for focus, and this ended up being rolled back.
I think it is worth filing an issue. Maybe we should update the spec.
> if the Working Group insists on a puritan stance
I don't think this comment helps moving the discussion forward.
> As mentioned, Chrome currently defaults to offering screens first, and this is something that I would very much like to change.
I like this.
We already discussed in a past meeting the possibility for Chrome to do this change without waiting for either this PR or any additional spec change by introducing Chrome specific APIs.
As an example, Chrome did a great work moving the default RTCPeerConnection from PlanB to Unified Plan (congrats on that!) without requesting any change from WebRTC specs.
Similarly, Chrome can extend values provided to getDisplayMedia to do this migration.
One approach would be to extend DisplayMediaStreamConstraints with a Chrome-specific 'defaultingToScreen' member, that could be true initially, then false, then removed.
As of the debate of reusing constraints or not, I would like to summarise why I do no think we should use constraints for this:
- Using constraints is enforcing a model that is not great for getDisplayMedia: we do not like exact constraints, we do not like some constraint values ('screen'). We would need to add specific rules that people will need to read and understand. This is harder than it should: just looking at a self explanatory type declaration should be all that is needed here.
- Using constraints is not future proof as it restricts the type of hints we might use to a fixed set of values. In the future, we might want to extend the selection hints: prefer capture 'self' tab, prefer capture 'same-origin isolated tab'... A separate property allows greater flexibility.
- There is consensus that constraints are overly complex (see comment from media capture depth) and that we should try to not extend usage of constraints if there is a nice alternative.
- There is no real downsides to introducing a new property in DisplayMediaStreamConstraints AFAIK, which makes it a nice alternative.
--
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1026748641 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 11:35:06 UTC