- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2022 11:24:56 +0000
- To: public-webrtc-logs@w3.org
> They can modify their application to not tag more elements than strictly necessary. That is not true in general, given how the web is authored today. Web pages embed adds and do not control what adds will do (they might well do fingerprinting so will generate CropTargets) Web pages are running in processes that run unrelated other pages, especially on small devices. > That error is in a different document. There is a communication channel between the two, otherwise there would be no CropTarget. > Having an async design increases everyone's flexibility in handling newly surfaced concerns such as this. The requirement for an async mechanism is based on an implementation that is showing big limitations. It seems best to spend some time on improving the implementation as much as possible, then to look at whether async is actually required. I'll be happy to provide feedback to get great performances while keeping API sync. Asking for async just in case it might be useful in the future does not seem like a good way to proceed. > 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. As said before, you can get the best of both worlds (no big repository/privacy issue, no latency in 99.99% cases) without too much issue. There is no need for an async API to achieve this. > 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? I don't think so. First, this creates potential privacy issues that we should avoid since produceCropTarget can be called without any permission. cropTo requires some permissions so no big deal exposing it at this point. We usually select designs that avoid those kind of issues hence the cropTo appeal. Second, produceCropTarget will rarely fail. When it will fail, web applications will get broken. Typically a message will not be sent and the application will mysteriously hang. cropTo will sometimes fail and web applications will probably have an error recovery mechanism that will be able to cover both cases. If we want to allow the web application to understand the issue, all we might need is to reject with an error indicating that the CropTarget is invalid/a new one is needed. > > 11\. 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. It is always good to look at existing APIs and existing UA patterns. Deviating from these patterns is ok when we see clear shortcomings but we need to try applying how existing APIs/patterns deal with those same issues. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1129888809 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 11:24:58 UTC