forwardWheel() instructs the browser to set up an 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.

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

1. WebIDL is for JS, not infra

WebIDL is a security barrier separating JavaScript from browser code. It's not to be invoked in parallel between platform to platform code calls.

EventListener is a callback interface 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 instance" is not possible. It's also legacy, a glorified 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:

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,

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.