- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2022 10:41:39 +0000
- To: public-webrtc-logs@w3.org
> 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. Let's add it. We could specify that we allow the UA to fail for an implementation-specific reason. Or if we can't agree on that, we can document that some implementations do that. > 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. Presently, in Chrome's implementation, it's global to all documents embedded within a given tab. Other browsers are free to implement with no limitation at all. Note that it's hard to come up with an app that would legitimately need more than 1-5 such tokens, so I don't think we'll have interop issues here if Chrome limits to 100 and Safari to 200. > 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. That's an interesting consideration. I can think of some mitigations, but when the time comes, I might need to tweak the Chrome implementation to address this. Having an async design increases everyone's flexibility in handling newly surfaced concerns such as this. > 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? Tagging at cropTo() time increases the time until the first frames are cropped and therefore reduces app performance - an important consideration for a highly ranked constituency. (IPC, start tagging in the render pipeline, etc.) Tagging as soon as we call produceCropTarget() - our current implementation - means tagging elements incurs non-zero cost. It is good that we dissuade the application from making excessive calls without good reason. > 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. They can modify their application to not tag more elements than strictly necessary. > cropTo time so it seems best to keep it the single error handling point. That error is in a different document. > 6. Is Chrome having a similar restriction for MessagePort creation? Why is Chrome fine with synchronous MessagePort creation? I was not around when MessagePort was designed and implemented. I cannot tell you whether compromises were made, or for what reason. -- Consider, btw, that we're likely going to want to expand the API in the future, so that it would work with cropping a track derived of capturing ANOTHER tab. We don't need to get consensus on that just yet, but it's good to keep doors open. So what will we want then? Would it not be nicer if technical limitations are surfaced as errors on the tab that produced the error? Would it not be better that produceCropTarget() fail in the captured tab, rather than cropTo() in the capturing tab? -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1129852353 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 10:41:40 UTC