Should applyConstraints reject when track is muted?

[youennf]

When track is muted, web application could in theory apply constraints.
This might have side effects, for instance camera reconfiguration.

I wonder whether we should reject applyConstraints for muted tracks, say with NotAllowedError.

[alvestrand]

I think this would be disruptive to use cases like changing the track resolution while track is muted; apps would have to remember that the applyConstraints was rejected and add an unmute handler to retry the applyConstraints at that time.
This seems profoundly unnatural, and likely to break existing apps in unexpected ways.

Suggest not to do it on the basis of backwards compatibility.

[youennf]

this would be disruptive to use cases like changing the track resolution while track is muted

Is that a use case though?

Also, it is unclear to me whether a UA can easily validate that the constraints will be respected when it does not have access to the device.

If rejection happens to be a compat issue, we could queue the constraint request until the source is unmuted.
Or we could do a workaround like pretending that apply constraints succeed without changing the actual HW device (and then apply the changes when track gets unmuted, call configurationchange if needed).

[eladalon1983]

This seems profoundly unnatural, and likely to break existing apps in unexpected ways.

I agree with this.

Web applications need to check a myriad aspects of the state right before taking action (e.g. track stopped, track muted). In an ideal world, they do. In our world, I suspect that the typical Web app is riddled with "gracelessly" handled edge cases that are "too rare to bother with."

If we can reduce the number of edge cases that Web apps "should" handle, but that they typically don't handle, I think that would be a good thing.