W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2022

Re: [mediacapture-region] Why expose produceCropTarget at MediaDevices level? (#11)

From: Yoav Weiss via GitHub <sysbot+gh@w3.org>
Date: Fri, 13 May 2022 08:28:25 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1125790108-1652430504-sysbot+gh@w3.org>
> Note though that element.id is not sufficient, we need a reference to the document. In our case, the iframe was ok with being embedded into the page, maybe this is a good enough restriction?

@youennf - that seems to be a very liberal restriction when dealing with cross-origin iframe's internal structure.. I doubt this will fly.

As I'm reviewing the [related intent](https://groups.google.com/a/chromium.org/g/blink-dev/c/eZE9LTJMUlk/m/UKs2m7UnAwAJ), it seems to me that:
* The element ID based solution won't enable the captured app to know of cases where the crop failed and respond accordingly (e.g. notify the user, etc). The captured app would just pass along an ID and hope for the best, which doesn't fully covers the RegionCapture use case.
* At the same time (and as @eladalon1983 pointed out), there's no other use case for the generic mechanism.

The former is also the reason why the handle creation [needs to be async](https://github.com/w3c/mediacapture-region/issues/17). Due to that, it seems unavoidable to create new API surface for that creation. While it can be generalized in the future, it seems premature to try to do that without any use cases, beyond RegionCapture.

GitHub Notification of comment by yoavweiss
Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1125790108 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 13 May 2022 08:28:26 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:57 UTC