[w3c/pointerlock] Which Element should receive scroll events if a wheel listener changes pointer lock target? (Issue #112)

gastonrod created an issue (w3c/pointerlock#112)

While working on a CL to fix pointer lock scrolling in chromium, [this question popped up](https://chromium-review.googlesource.com/c/chromium/src/+/8592820/comment/dca2a9a6_96944e1b/).

[Per the spec](https://www.w3.org/TR/pointerlock-2/#the-pointer-lock-state-definition), scroll events should be redirected to the pointer lock target:
> The [pointer-lock target](https://www.w3.org/TR/pointerlock-2/#dfn-pointer-lock-target) receives all relevant user generated [MouseEvent](https://www.w3.org/TR/pointerevents4/#dom-mouseevent) events: namely, all user-generated mousemove, mousedown, mouseup, click, dblclick, auxclick, and wheel [[POINTEREVENTS](https://www.w3.org/TR/pointerlock-2/#bib-pointerevents)].

If a listener to the wheel events on the pointer-lock target changes the pointer-lock target to a different element, what should happen? Currently (after the linked change is landed), the current pointer-lock target will always be the target of mouse events. This means that the second element would be the one scrolled. From a demo page:
```
4210.0 ms: A.requestPointerLock() resolved
4213.5 ms: pointerlockchange: lock=a, A.scrollTop=0, B.scrollTop=0
5439.8 ms: wheel handler on A: event.target=a, deltaY=93.3333251953125, lock at handler=a
5441.7 ms: wheel handler called B.requestPointerLock()
5443.1 ms: B.requestPointerLock() resolved
5445.8 ms: after wheel handler frame: lock=b, A.scrollTop=0, B.scrollTop=0
5455.9 ms: pointerlockchange: lock=b, A.scrollTop=0, B.scrollTop=0
5473.2 ms: scroll on b: lock=b, A.scrollTop=0, B.scrollTop=208
5538.5 ms: scroll on b: lock=b, A.scrollTop=0, B.scrollTop=243.1999969482422
7148.4 ms: pointerlockchange: lock=none, A.scrollTop=0, B.scrollTop=243.1999969482422
```

With this event log we can see that a lock was requested on (A), I scrolled and a listener changed the pointer-lock target to (B), and then (B) was scrolled. To me, this seems in line with the spec since the pointer lock target is the element that is receiving the events at all times, but it may be the case that for this type of situation (A) should be the element receiving the scroll events because the original action was targeting (A).

Behavior in both Chromium and Firefox is currently broken as scroll events are not redirected to the pointer lock target, so this isn't reproducible in release builds. Haven't tested Safari.

Demo here: https://jsfiddle.net/v6nx8r2b/

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/issues/112
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/pointerlock/issues/112@github.com>