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

[whimboo]

The problem is that a Wheel input source in the WebDriver classic specification does not have x and y coordinates. But then we run into a problem in get coordinates relative to an origin. Here the x and y properties of the input source need to be used to calculate the target points.

Ideally the current position of the pointer should be used, but given that it is a different input type there is no access to it. On #1409 the proposal was made to add the scroll action to the pointer input type, and that would have allowed us to actually work with the current pointer position.

Right now both start x and start y of a scroll action always refer to 0, 0 which is similar to the viewport origin.

Having scroll as action for a pointer input device would also make it much more simpler to handle in case of multiple pointer input devices.

[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