- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Oct 2024 15:14:37 +0000
- To: public-webrtc-logs@w3.org
> The UA can prompt instead of scroll (or prompt instead of zoom +/- button). No promise needed. The established pattern is to use permission policies and return a promise through which the application can detect whether permission was granted or not. Your suggestion does not align with any precedents I am familiar with, nor does it sound desirable. Further, [this comment](https://github.com/w3c/mediacapture-screen-share-extensions/issues/14#issuecomment-2429520269) shows how Youenn made the perfect argument for permission policies. Namely, he raised the need for user agents to allow revocation. I completely agree, and here we benefit of the fact that permission policies have already been specified and implemented, saving us the need to roll our own - and the mistakes we would surely have made. > Doesn't CSS already have > ... > Worst case: a div.enableGestureForwarding to forward gestures to the video element underneath. We have clear feedback from developers about what they need to serve their users. The current API shape provides them just that. We do not have any indication about how limiting to video elements would improve the lives of users or developers. > The attack vector was explained in [#14 (comment)](https://github.com/w3c/mediacapture-screen-share-extensions/issues/14#issuecomment-2426657705). Tying scrolling to playback seems a reasonable direction to help UAs mitigate this. It has been sufficiently demonstrated that limiting to specific elements would not mitigate that attack vector. It would only annoy developers, but it won't stop abuse. > I would leave it up to the UA to make a determination. I can easily think of how these heuristics could backfire. I cannot imagine what it would gain us. (See previous comments about not preventing abuse.) > I don't believe it does that. If we agree on "multiple target-elements", I assume we agree interaction is carried upstream so it affects all of them. I don't understand this comment. > Both `enableGestureForwarding` and `forwardGestures` are better names than `captureWheel`. I see no reason to go backwards on naming. If you have a name that matches with the `captureWheel()` shape, I am fine with that. For example, `forwardWheel(element)`. But since you do not like `forwardGestures(element, gestures)`, that one is out. > With my co-chair hat, I ask that we not "assign intent or interpretations to other contributors' comments". Mozilla has not formally objected to anything yet. You wrote: "I do not favor this API." Regardless of formality, it follows that a pivot to this API shape is not helping us reach consensus. But if you do prefer `forwardGestures(element, gestures)` over other alternatives that are currently on the table, that is still an option for me. --- > How do people think of the list of items in #13 (comment). I would appreciate: 1. An exhaustive list of open issues (or as close to exhaustive list as can be reasonably expected). 2. An indication of which points have been satisfactorily address and may be closed. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/13#issuecomment-2429565114 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 22 October 2024 15:14:37 UTC