"get coordinates relative to an origin" fails for "wheel.scroll" actions and a "pointer" origin about webdriver

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Perform Actions: "scroll" action incompatible with pointer origin type.

The full IRC log of that discussion

<jgraham> Topic: Perform Actions: "scroll" action incompatible with pointer origin type
<jgraham> github: https://github.com//issues/1758
<shs96c> scribenick shs96c
<shs96c> scribenick: shs96c
<shs96c> jgraham: the spec has a bug that claims you can use the wheel input source at a coord relative to the pointer, but the wheel input source does not have a pointer, and you can scroll on a specific element or at a specific point, but the scroll wheel itself doesn't have a current position.
<shs96c> jgraham: this is unlike an actual mouse with a scroll wheel, where the scroll happens at the current point position. We merge the PR that says if you have a scroll input type, you can't accept `pointer` as the origin for that action.
<shs96c> jgraham: So that raises the question of why `scroll` isn't an action on a `pointer`? Is it worth making `scroll` an action on a `pointer` type or not?
<shs96c> q+
<shs96c> ack next
<shs96c> shs96c: I think it probably is

[whimboo]

jgraham: So that raises the question of why scroll isn't an action on a pointer? Is it worth making scroll an action on a pointer type or not?
q+
ack next
shs96c: I think it probably is

@shs96c, I assume that means that to keep backward compatibility we should leave the wheel input device with the scroll action but also make it available for the pointer device?

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Backward compatibility for "get coordinates relative to an origin" fails for "wheel.scroll" actions and a "pointer" origin.

The full IRC log of that discussion

<jgraham> Topic: Backward compatibility for "get coordinates relative to an origin" fails for "wheel.scroll" actions and a "pointer" origin
<gsnedders> We could presumably also just mechanically try running commands and see if they return "unknown command".
<jgraham> Github: https://github.com//issues/1758
<jrandolf> gsnedders: Mmm, indeed, we can have a cron job that tries this.
<jgraham> whimboo: Scroll needs coodindates, which makes it look like a pointer. Should we add wheel as a pointer type?
<jgraham> gsnedders: Does pointer events have something we can copy here?
<jgraham> jgraham: This only makes sense for mouse-type pointers I think. Easiest might be to just add coordinates to scroll and if you want it in sync with the pointer position you have to do that manually.
<jrandolf> q+
<jgraham> jgraham: We should have the discussion on the github issue.
<jgraham> ack next
<jgraham> jrandolf: Isn't scroll already based on the current point?
<jgraham> whimboo: For wheel input source there aren't coordinates, it's not synced with the pointer position.
<jgraham> jrandolf: Could we use the coordinates from mouse events?
<jgraham> jgraham: That seems unsafe, because it changes the behaviour of tests
<jgraham> gsnedders: What's the current behaviour?
<jgraham> [discussion of current behaviour]
<jgraham> jrandolf: Chromium seems to use current mouse position
<jgraham> gsnedders: I think SafariDriver probably does that too, but I'm not sure
<jgraham> whimboo: There could be multiple mice
<jgraham> gsnedders: Someone should write a test to demonstrate the current behaviour
<jgraham> whimboo: I wrote a test
<jgraham> whimboo: I'll comment on the issue with the current behaviours

[gsnedders]

someone (@whimboo?) should edit make webdriver/tests/classic/perform_actions/wheel.py check clientX/clientY, with/without mouse move actions before the wheel action? and then we can observe existing behaviour here