Interaction between cropTo() and restrictTo()

[eladalon1983]

Assume the following code:

const stream = await navigator.mediaDevices.getDisplayMedia({selfBrowserSurface: 'include'});
const [track] = stream.getVideoTracks();
track.cropTo(token1);  // line1
track.restrictTo(token2);  // line2

Assume that both token1 and token2 are valid tokens (rather than null), and might even be the identical. Further, the relative order of cropTo() and restrictTo() is irrelevant.

Question: Should we specify that line2 throws an error, or should we specify that it overrides line1?

[eladalon1983]

I favor throwing an error, because I am concerned that Web developers might otherwise be confused about the interaction between cropTo() and restrictTo(), and might mistakenly think that the operations can be composed one on top of the other.

The "override" behavior can still be achieved by calling cropTo(null) right before calling restrictTo(token2).

[markafoltz]

PR #35 updates the spec to implement override behavior, at least in the cropTo() => restrictTo() direction. Unless there are objections to that solution, this can be closed out.

[eladalon1983]

Thanks for the reminder.

To document some rationale for the selected behavior:

1. The behavior of cropTo / restrictTo overriding each other did not appear to confuse developers, based on some unofficial questioning I did and my own experience with the API. In fact, it made for less tedious coding (see sub-capture-demo.glitch.me).
2. If we chose to throw an error, it'd have been good to also expose crop-state / restriction-state, so that applications could avoid this error. It's unclear that such a getter would serve any other purpose.

Closing this issue now. If anyone objects - please comment and we can reopen.