Re: [mediacapture-region] What makes CropTarget special to require an asynchronous creation? (#17)

> Based on @eladalon1983’s [previous comment](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1027843349) here, minting _[can fail](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/media/capture/crop_id_web_contents_helper.h;l=38;drc=f10df0040d17b75ac96491b1c009550e97778bc9)_.

Thanks for bringing this, I missed that bit of information. A few related thoughts:
1. The produceCropTarget algorithm is currently not describing that it can fail. As it is, it cannot fail. If we think this is important, we should change the spec to describe when it fails so that implementations can have interop.
2. It is not clear how this 100 restriction kicks in. If it is per renderer process, it can be done inside the renderer process. If it is global to all renderer processes, I agree that some async IPC is the usual way to deal with this.
3. Can this 100 restriction be used as a cross-origin/cross-storage-partitioning messaging channel, say between two iframes living in the same process (out-of-process iframes is not a thing in all platforms) or between two iframes with the same origin but different top origins, or in case of same-process-but-cross-origin navigation? If this threat is real, we should probably change the design/implementation of such APIs. Having the failure at cropTo time is of course safe given capturer has access to capturee content.
4. Elad mentioned in the past that Chrome current implementation is doing some surface labelling processing at CropTarget creation time and that it might be better to move this to cropTo time. Would that alleviate the need for this restriction? Is Chrome's plan to keep that 100 restriction or to remove it at some point?
5. In general, APIs that can fail like this in odd cases is not really appealing, I doubt web developers will actually think of handling this error case and I am not sure what they can do to recover from this. Web applications will be better served with UA implementations that cannot fail. Web developers will have to deal with errors at cropTo time so it seems best to keep it the single error handling point.
6. Is Chrome having a similar restriction for MessagePort creation? Why is Chrome fine with synchronous MessagePort creation?

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


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

Received on Wednesday, 18 May 2022 09:40:35 UTC