-
Notifications
You must be signed in to change notification settings - Fork 195
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
"get coordinates relative to an origin" fails for "wheel.scroll" actions and a "pointer" origin #1758
Comments
get coordinates relative to an origin
fails for wheel.scroll
actions and a pointer
origin
The Browser Testing and Tools Working Group just discussed 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 |
@shs96c, I assume that means that to keep backward compatibility we should leave the |
The Browser Testing and Tools Working Group just discussed 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 |
someone (@whimboo?) should edit make |
The problem is that a Wheel input source in the WebDriver classic specification does not have
x
andy
coordinates. But then we run into a problem inget coordinates relative to an origin
. Here thex
andy
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 thepointer
input type, and that would have allowed us to actually work with the current pointer position.Right now both
start x
andstart y
of ascroll
action always refer to0, 0
which is similar to theviewport
origin.Having
scroll
as action for apointer
input device would also make it much more simpler to handle in case of multiple pointer input devices.The text was updated successfully, but these errors were encountered: