Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where do forwarded "wheel" events fire? #51

Closed
tidoust opened this issue Dec 4, 2024 · 2 comments · Fixed by #56
Closed

Where do forwarded "wheel" events fire? #51

tidoust opened this issue Dec 4, 2024 · 2 comments · Fixed by #56

Comments

@tidoust
Copy link
Member

tidoust commented Dec 4, 2024

The spec fires the wheel event at a the "controller.[[Source]]'s viewport". I'm struggling to understand what viewport means here. What interface and instance does this refer to?

There is a notion of viewport in CSS, but that is not an interface at which a "wheel" event may be fired. There is also a Viewport interface but it does not inherit from EventTarget.

Wheel events typically fire at an element and bubble to the Document and Window. Is the viewport here meant to be the Document or Window?

In other words, how does an application listen to these forwarded "wheel" events?

@eladalon1983
Copy link
Member

controller.[[Source]] is intended to reference the captured tab (this set of APIs only works when capturing tabs). The wheel event is supposed to be fired in that other tab, as it is normally fired when the user interacts directly with that other tab. If you are able to suggest a clearer way to convey this in the spec, I'd be happy to do so.

@tidoust
Copy link
Member Author

tidoust commented Dec 16, 2024

Got it! That means you're not firing the wheel event "at the controller.[[source]]'s viewport", but rather at the element in the controller.[[source]]'s viewport that would be targeted by the event if the wheel action had originated from that viewport.

In UI Events parlance, that element seems to be called the topmost event target. I would end the forward wheel event algorithm with "at the topmost event target of the controller.[[Source]]'s viewport".

But I missed another problem (which probably also explains why I got confused): "fire an event" can only be triggered within an event loop. In your case, that event loop should be that of the captured viewport. Right now, the algorithm fires the event from within steps that run in parallel (so outside of any event loop) and in the context of the capturing viewport. That is doubly invalid.

The last step could perhaps be re-written to something like:

  1. Queue a global task on the user interaction task source of controller.[[source]]'s current realm, given that realm's global object, to fire an event named "wheel" using WheelEvent with the x attribute initialized to scaledX, the y attribute initialized to scaledY, the deltaX attribute initialized to event.deltaX and the deltaY attribute initialized to event.deltaY, at the topmost event target.

(I note the UI Events spec also has the notion of wheel event transaction to group a series of wheel events that may be relevant when forwarding as well)

There may be an easier way to express "forward a UI event with the following coordinates" in simple terms. I haven't thought deeply about it, I was just confused because I did not understand where the event was supposed to fire ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants