[mediacapture-surface-control] Novel interception of input has undesirable side-effects (#67)

jan-ivar has just created a new issue for https://github.com/w3c/mediacapture-surface-control:

== Novel interception of input has undesirable side-effects ==
[forwardWheel()](https://w3c.github.io/mediacapture-surface-control/#dom-capturecontroller-forwardwheel) instructs the browser to set up an [EventListener](https://dom.spec.whatwg.org/#callbackdef-eventlistener) for itself, under the hood, for use by its own platform (c++) code to listen for input and execute its (c++) [forward wheel event algorithm](https://w3c.github.io/mediacapture-surface-control/#dfn-forward-wheel-event-algorithm).

This seems problematic (1) editorially and (2) behaviorally:

#### 1. WebIDL is for JS, not [infra](https://infra.spec.whatwg.org/)

WebIDL is a security barrier separating JavaScript from browser code. It's not to be invoked [in parallel](https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel) between platform to platform code calls.

[EventListener](https://dom.spec.whatwg.org/#callbackdef-eventlistener) is a [callback interface](https://webidl.spec.whatwg.org/#idl-callback-interfaces) meant to be implemented by JavaScript objects passed into platform API methods. Unlike a normal interface (which the browser provides), a callback interface is something JavaScript application code implements to let the browser call into it. In this case, EventListener is defined as a callback interface with a `handleEvent()` method, meaning JavaScript can supply an object with a `handleEvent()` function to respond to events.

Critically, it is not an interface, and cannot be instantiated so _"creating a new Web IDL [EventListener](https://dom.spec.whatwg.org/#callbackdef-eventlistener) instance"_ is not possible. It's also legacy, a glorified [callback function](https://webidl.spec.whatwg.org/#dfn-callback-function).

Platform code would instead need to express desired behavior directly somehow.

#### 2. Surprising side-effects of the event listener pattern

Having a browser method create real event listeners under the hood would have observable side-effects relative to other JS listeners:
```js
element.addEventListener("wheel", a);
controller. forwardWheel(element);
element.addEventListener("wheel", b);
```
Here, `a` will run ahead of the browser forwarding the wheel event, and `b` will run after.

If the application temporarily pauses forwarding like below, 
```js
controller. forwardWheel(null); // pause

// some time later
controller. forwardWheel(element); // unpause
```
Then now _both_ `a` and `b` suddenly run ahead of the browser forwarding the wheel event.

This might lead to surprises, e.g. if either `a` or `b` (conditionally) calls `event.stopImmediatePropagation()`.

It might be better to specify this without these side effects, either by having the user agent always grab the input first before it gets to JS, or implement it as a (preventable) default behavior.

If we move the API to HTMLVideoElement, it might significantly impact on how we specify this, perhaps letting us specify more traditional ways of consuming this input.

Please view or discuss this issue at https://github.com/w3c/mediacapture-surface-control/issues/67 using your GitHub account


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

Received on Wednesday, 29 January 2025 01:28:21 UTC