Re: [mediacapture-region] Is BrowserCaptureMediaStreamTrack needed? (#10)

`BrowserCaptureMediaStreamTrack` was **not** introduced because of cloning. True, I have attached some mandates to `BrowserCaptureMediaStreamTrack.clone()`. But it's possible to put those elsewhere. Rather, the reason was...

[DisplayCaptureSurfaceType]( exposes whether the user shared a tab, but not **which** tab, and definitely not whether it's the current tab. BCMST allows us to expose `cropTo()` only on such tracks where it is (potentially) valid to call.

There are alternatives:
* Expose `cropTo` more widely and expect applications to call it "optimistically" and be robust to failure.
* Rely on the yet-unadopted [Capture Handle]( (shameless plug, cough-cough...).
* OCR-like hacks.

But exposing a control only where it is (potentially) valid seems to me like the most elegant, self-contained approach.

If we find in the future that we want to expose `cropTo()` on additional surfaces, there'll be nothing stopping us. But I don't expect that this is coming too soon. Other tabs - yes. But windows and screens - not with the current CropTarget. So arguably window/screen-cropping would be entirely separate APIs.

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 25 January 2022 19:29:02 UTC