- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Aug 2018 21:21:26 +0000
- To: public-media-capture-logs@w3.org
> but always return OverconstrainedError when these properties are set
Sorry, I should have said they will be ignored, because they're not required (`min`, `max` or `exact`) constraints.
E.g. `track.applyConstraints({logicalSurface: true})` would succeed and be indistinguishable from `track.applyConstraints({})` (`OverconstrainedError` would only happen if we used a `max` constraint, but I can't think of an example, assuming https://github.com/w3c/mediacapture-screen-share/pull/73 is merged).
> MediaTrackSupportedConstraints should include these properties as well, because they can be set
Well, because they are "supported", but yes. The current definition of [getSupportedConstraints](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-getsupportedconstraints) does not explicitly guarantee that they do something when set, only that the browser implements those constrainable properties (not that they're effectively actually constrainable).
> I was thinking it might be confusing for the user, as we are defining but not actually supporting them.
Would it be more confusing than `deviceId`? We "support" them, they're just defined to be changeable, much like `deviceId` (which already appears in getSupportedConstraints()).
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/66#issuecomment-417110051 using your GitHub account
Received on Wednesday, 29 August 2018 21:21:31 UTC