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

(I am sure Youenn knows, but if others want to join the conversation, one line of background: In Chrome, applications run in a "render process", and there is a "browser process" coordinating them. Cross-origin applications run in different processes.)

Back to the produceCropTarget Promise.
I think the implementation in Chrome, and its constraints, might have analogues in other browsers. Let's examine it.

* A CropTarget is produced in one document (D1), then used by another document (D2) in the same browsing context.
* There could be many more cross-origin documents in the browsing context, and many processes.
* When D2 calls cropTo(X), the UA has to validate that X is a valid CropTarget.
* It is undesirable to query all documents and check if any of them have produced X. Rather, the browser process holds a central repository of valid CropTargets and their associated browsing context. When cropTo() is called, this repository is consulted.
  * If the CropTarget includes the origin, this can be simplified, but it still requires an RTT of IPCs, D1->BROWSER->D2->BROWSER->D1. An insufficient improvement.
* That means that produceCropTarget inserts into that BP-based repository.
* That also means that, if we don't impose a cap on number of CropTargets, an application can directly affect the memory consumption of the browser process. That is undesirable.
* So there is a cap on the number of CropTargets a browsing context could have.
* That means that when attempting to produce a CropTarget, there has to be IPC with the browser process before we know that we're in the happy case, and a CropTarget can be produced.
  * **Side-note:** For security's sake, it's also more obvious that things are safe, if the underlying token for the CropTarget, is assigned by the trusted browser process, rather than communicated to it from the render process. For example, it becomes trivial to guarantee use a low-bit-count token behind the scenes, guarantee no collisions, and thus have a simple and efficient implementation in the rendering pipeline.
* That means that produceCropTarget has to either return a Promise (which is resolved after IPC with the browser process), or it has to block on this IPC.
* Blocking JS applications on IPC is something Chrome aims to avoid.

As mentioned, Chrome's implementation problems are Chrome's problems, but (a) I suspect other implementers will have similar issues and (b) the cost of resolving these issues is negligible.
Returning a Promise gives implementers flexibility.

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 Thursday, 27 January 2022 11:14:00 UTC