New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
restrictTo() algorithm questions #18
Comments
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. -- |
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 ;( |
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?) |
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 |
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 w3c/mediacapture-region#17 |
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 |
Got it now! Thanks for explaining @eladalon1983 |
I have two questions in the algorithm below:
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?
The text was updated successfully, but these errors were encountered: