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

> That would probably be specified by adding a CropTarget slot on HTMLElement directly.

Exposing the interface on `HTMLElement` is possible, but I think exposing on something more media-related or RTC-related gives better encapsulation. The vast majority of `HTMLElement`s do not end up serving as a crop-target. It's best of both the controls as well as their documentation are more localized to where they're relevant.

> This would also solve probably the cloning element cropTarget issue.

I don't think so, but possibly I am missing your point.
As I see it, there are two "cloning issues" at play:
1. Cloning of the **target**. A clone of an `HTMLElement` is a distinct `HTMLElement`, and should have a new `CropTarget`. This is equally easy to express with either approach (`MediaSession.produceCropTarget` vs. `HTMLElement.cropTarget`). In terms of communicating the selected approach, I think it's neater to express with `produceCropTarget` than with the alternative, but possibly this is subjective.
2. Cloning of the **track**. I believe this is orthogonal.

> I am also wondering why we even need a promise there.

The intention is:
1. Allow `produceCropTarget()` to execute quickly for applications that don't immediately need the result. (E.g. cache it for later, in case gDM is called.) Allow JS execution to proceed immediately without blocking on IPC message-and-response.
2. Allow implementations flexibility (explained below).

I'm using the working assumption that we agree on no1 (let's discuss oherwise) and moving to discuss no2. Consider the example of Chrome. Returning a Promise gives Chrome the flexibility to produce the CropTargets' underlying ID in what we call the "browser process". This means that when `cropTo(x)` is called, we can validate `x` in the (trusted) browser process, check that it's a valid CropTarget (always necessary), and that the caller is allowed to cropTo it (relevant while we limit the spec to self-capture; orthogonal issue). JS execution proceeds immediately after `produceCropTarget()`, but an IPC message is sent to the browser process, and the Promise is resolved when the response IPC comes from the browser process.

Using a Promise also makes it easy to convince ourselves that Chrome's implementation suffers no hidden race conditions. Consider **if a Promise were not employed** in this scenario:
* Cross-origin documents D1 and D2 cohabitate in a tab. Each documents has its own associated process.
* D1 produces a CropTarget. D1 immediately gets a token **before** any IPC happens, but some IPC would have to complete before all relevant processes hear of this CropTarget.
* (For the sake of argument, let's assume that CropTarget is both transferable as well as serializable.)
* D1 sends the CropTarget to D2. Maybe using postMessage, maybe over the network.
* D2 tries to use CropTarget.

In this scenario, it is required that the CropTarget D1 minted would be known to the cropTo() code-paths before D2 tries to call cropTo(), or that the cropTo() code-paths be robust to such reordering. This can be hard to reason about. But if we return a Promise, then we get no1 immediately, and we can resolve the Promise at our leisure, when it's patently obvious that the CropTarget has been fully propagated.

Note that the Promise gives flexibility. If Safari's implementation can convince itself there is no race even if the CropTarget is produced immediately, then Safari can return an already-resolved Promise.

Editorial: To make this more accessible, could you please add \`\`\`webidl before the code snippets before and \`\`\` after them?


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 25 January 2022 19:03:32 UTC