Open eladalon1983 opened 3 years ago
We should elaborate here how these constraints should work "As a capability", like we do in mediacapture-main.
We also don't appear to list restrictOwnAudio
in the MediaTrackCapabilities WebIDL which seems like an omission we should fix. I see no reason why this constraint should be omitted there, so this seems editorial to me. It should follow the constrainable pattern like all the other constraints, unless the WG decides otherwise (which I don't believe it has).
As to the OP of whether it is "settable", if we mean can it be applied as a constraint, then it seems like it already can: "As a constraint, this property can be constrained resulting in a source with own audio restriction enabled or disabled."
During the last editors' meeting, the question arose of whether
restrictOwnAudio
should be settable. It seems to me that the best thing to do would be to havegetCapabilities()
return asequence<boolean>
and let the UA decide whether it supports changing this constraint on the fly.