restrictTo() algorithm questions

[beaufortfrancois]

I have two questions in the algorithm below:

When invoked with cropTarget as the first parameter, the user agent MUST execute the following algorithm:

1. If this is not a restrictable MediaStreamTrack, return a Promise rejected with a new NotSupportedError.

2. Let p be a new Promise.

3. Run the following steps in parallel:

   1. Let E be cropTarget.[[Element]].

   2. If E is not a valid restriction target for this, return a Promise rejected with a new InvalidStateError.

Is the "If this is not a restrictable MediaStreamTrack" first check needed as the "If E is not a valid restriction target" second check also verifies that "this" is not a restrictable MediaStreamTrack as well?

Moreover, what are the reasons for invoking "Run the following steps in parallel"? Which parts is actually async?

[eladalon1983]

The first set of checks is done synchronously over the MediaStreamTrack. (In Chrome that'd happen in the render process.)

Checks involving the target-element are necessarily asynchronous, because the the target-element may be in an out-of-process iframe[]. The original tests, involving the MediaStreamTrack, are repeated at this stage so as to ensure they still* hold, given that the asynchronicity might have allowed that to change in the intervening time.

-- [*] In Chrome, they'd be carried out in the browser process rather than in the target element's process, btw. But in either case, it can't be done in the MST's own process, except for in those occasions where the Element and the MST are in the same frame.

[beaufortfrancois]

I wonder if the spec would benefit from a note adding those details as it's not clear immediately why the asynchronousity is needed there. I don't see much details in https://www.w3.org/TR/mediacapture-region/ as well ;(

[eladalon1983]

I think the clarification might only benefit a few very attentive readers such as yourself, and would be distracting for the majority of readers. But I could be wrong. I think it'd be good to reconsider it if someone else raises the same question and suggests a clarification too. Wdyt?

(Or maybe you could cite a precedent of such a clarification?)

[beaufortfrancois]

I guess this will go away when https://github.com/w3c/mediacapture-region/issues/17 is resolved. I think we can close it then.

[eladalon1983]

I guess this will go away when w3c/mediacapture-region#17 is resolved. I think we can close it then.

I don't think so, because the asynchronicity here is inherent to restrictTo(), and would not be affected by the asynchronicity of the minting of the token.

[beaufortfrancois]

You said "Checks involving the target-element are necessarily asynchronous, because the the target-element may be in an out-of-process iframe" which I read as "Checking whether it is a valid CropTarget is necessarily asynchronous". Since "we define a valid CropTarget as one returned by a call to CropTarget.fromElement() in a document that is still active.", I assumed it was tied to https://github.com/w3c/mediacapture-region/issues/17

[eladalon1983]

After minting is done, the underlying target-element may still be detached from the DOM and even garbage-collected. Whether that has happened would not be known to the document calling restrictTo(token); not without IPC.

[beaufortfrancois]

Got it now! Thanks for explaining @eladalon1983