- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Sep 2021 17:22:55 +0000
- To: public-webrtc-logs@w3.org
> That would prevent throwing for instance if adding an audio constraint exact property added in the video constraints part of a getDisplayMedia call. I just tested it and browsers seem to consistently allow this.
That seems fine to me, as I see no support for throwing in that specific case. With gDM, "an audio constraint ... added in the video constraints" is not hitting _"[a constrainable property applicable to display surfaces](https://w3c.github.io/mediacapture-screen-share/#dom-mediadevices-getdisplaymedia)"_.
Instead, we generally ignore _"[any constrainable property inside of CS that are not defined for MediaStreamTrack objects of type kind. This means that audio-only constraints inside of "video" and video-only constraints inside of "audio" are simply ignored rather than causing OverconstrainedError.](https://w3c.github.io/mediacapture-main/#dom-mediadevices-getusermedia)"_
IOW no use in throwing over validity of constraints already ignored.
> Then, instead of adding a ConstrainDOMString, we would add an enum on displaySurface.
> Or we could name it preferredSurface to make it clear this is a preference, not a choice.
> We would get better WebIDL typing.
> And browsers would not have to start throwing on `navigator.mediaDevices.getDisplayMedia({ video : { displaySurface : { exact : 'window' }}})`.
Throwing is good, and browsers would still throw with your change. The only difference would be having WebIDL taking care of it for the browser, which seems a big API surface change for a very small benefit solely to implementers.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-926797874 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 September 2021 17:22:57 UTC