- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 14:59:53 +0000
- To: public-webrtc-logs@w3.org
> Your own proposal of `{overlay: element}` amounts to forwarding from an arbitrary element. It aims to limit forwarding to elements overlaid on top of an actively playing video element, but it fails to do so, because the workaround is trivial: No that's incorrect. The browser would check that the coordinates of the wheel event it received (and the trusted duplicate) puts it over the video element (the "hit zone" I was referring to). I thought this was obvious but I should have included it, sorry. One improvement this WG has made over Chrome's existing demo is to put the user agent in charge of coordinates instead of leaving that to web developers. But it still inherently seems to assume the passed-in element defines the hit zone (to the extent it talks about it at all). This is what I think is flawed, and fits my definition of _"forwarding from an arbitrary element"_. I see no checks here at all that input is over any preview at all. It's too loose of an API, and one I will not support. > ... If Media Capture Transform is used ... This feedback seems to be challenging what specific mitigations user agents will be able to construct. I suggest we leave that problem to the user agents. 7 of my 8 points were *not* primarily about mitigations, but about creating a superior API surface that naturally reflects the behavior I want (not contorted by the overlay use case). It fixes usability flaws and surprises inherent in the existing API once we start moving things around a bit. I suggest we focus on HTMLVideoElement first. We can extend it to HTMLCanvasElement later. There's precedent for that with `captureStream` -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-surface-control/issues/45#issuecomment-2624733271 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 14:59:53 UTC