1850148 - The first pointerMove action at (0,0) is "no-op" action

Status: RESOLVED WONTFIX

(Remote Protocol :: Agent, defect, P3)

Description

[Edgar Chen [:edgar]]

This is initially found in bug 1520785 comment 12,

Looks like defined in the spec, see step 7 of https://w3c.github.io/webdriver/#dfn-perform-a-pointer-move. Then the first pointermove action would be ignored if the coordinate is (0,0), like https://searchfox.org/mozilla-central/rev/0c682c4f01442c3de0fa6cd286e9cadc8276b45f/testing/web-platform/tests/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html#42. But it seems to work on other browsers, https://wpt.fyi/results/pointerevents/pointerevent_setpointercapture_inactive_button_mouse.html?label=experimental&label=master&aligned.

I have filed a spec issue for this, I am not sure if this is a spec issue or not, since other browsers behave differently.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Edgar Chen [:edgar] from comment #0)

I have filed a spec issue for this, I am not sure if this is a spec issue or not, since other browsers behave differently.

For which spec did you actually file this issue for? Do you have a link?

Also is this blocking the interop 2023 work? If yes and it would have a major impact we could prioritize the work. So how many tests are actually failing because of the current behavior?

Comment 2

[Edgar Chen [:edgar]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #1)

For which spec did you actually file this issue for? Do you have a link?

https://github.com/w3c/webdriver/issues/1545

Also is this blocking the interop 2023 work? If yes and it would have a major impact we could prioritize the work. So how many tests are actually failing because of the current behavior?

The pointerevent_attributes_hoverable_pointers.html which is in interop 2023 list is failing because of this. Another known failure is pointerevent_mouse_capture_change_hover.html, but it is not in the interop list.
We could workaround it by changing the tests, but it would be good if we could clarify behavior on webdriver.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:whimboo, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Edgar Chen [:edgar] from comment #2)

The pointerevent_attributes_hoverable_pointers.html which is in interop 2023 list is failing because of this. Another known failure is pointerevent_mouse_capture_change_hover.html, but it is not in the interop list.
We could workaround it by changing the tests, but it would be good if we could clarify behavior on webdriver.

Here some comments to the tests:

pointerevent_mouse_capture_change_hover.html:

• So is there a reason why the move to 0/0 has to be done at the beginning of the test? Why can't the mouse pointer be moved to that location at the end instead? It's only used to reset the hover and as far as I can see it shouldn't be a problem. Also keeping the line as is but moving to the clientWidth and clientHeight of the document element seems to make it work.
• Moving the first test of the file to the very end and also moving the mouse move to 0/0 to the end of each test makes the test pass. When the first test is kept at the current location it fails both other tests. I assume that something with the test Mouse down and capture to green is not correct.

pointerevent_attributes_hoverable_pointers.html

• Similar to the above, moving to the clientWidth and clientHeight within moveToDocument also makes it working here, whereby some other problems appear which cause the precondition to fail (these I haven't checked).

The above solution might be a workaround for these tests, so that the pointer doesn't have to be moved to a random position. We might still have to figure out how best to initialize the action chain for pointer events, and how important that is.

Comment 5

[Edgar Chen [:edgar]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #4)

Here some comments to the tests:

pointerevent_mouse_capture_change_hover.html:
It's only used to reset the hover and as far as I can see it shouldn't be a problem. Also keeping the line as is but moving to the clientWidth and clientHeight of the document element seems to make it work.

Yes, that's just to move the mouse away from either the green or blue element to reset the hover state. Moving to a position that isn't over either the green or blue element should work.

• also moving the mouse move to 0/0 to the end of each test makes the test pass.

I assume you mean moving this line to the end of test.
But I wonder why this makes a difference since it is a no-op action in gecko driver.

pointerevent_attributes_hoverable_pointers.html

• Similar to the above, moving to the clientWidth and clientHeight within moveToDocument also makes it working here, whereby some other problems appear which cause the precondition to fail (these I haven't checked).

Similar to the above, moving to a position that isn't over the test elements should work, I assume.

The above solution might be a workaround for these tests, so that the pointer doesn't have to be moved to a random position.

We could also add a dummy element and move pointer there to reset position, instead of using 0/0 position.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Edgar Chen [:edgar] from comment #5)

• also moving the mouse move to 0/0 to the end of each test makes the test pass.

I assume you mean moving this line to the end of test.
But I wonder why this makes a difference since it is a no-op action in gecko driver.

Yes, and it's not a no-op given that the mouse was moved before to some position on the viewport. Moving to 0/0 afterward will not have the same coordinates and as such actually performs this move.

We could also add a dummy element and move pointer there to reset position, instead of using 0/0 position.

Maybe this might actually be the best option here for now so that you can get the tests working and not have to move to some random position.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

FYI I created https://github.com/web-platform-tests/wpt/pull/42579 to land a test that covers the current behavior for the WebDriver specification. When it gets landed we will discuss on the referenced WebDriver issue if we can change the behavior or have to keep it because Chrome allows the initial movement to 0/0.

Edgar, the related tests from comment 0 have been updated and work now. I assume there is nothing blocking you anymore? Also when I had a look at the updated tests I saw that two different action chains are used, and I wonder why that is necessary and not a single action chain for all the pointer actions is used.

Comment 8

[Edgar Chen [:edgar]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #7)

Edgar, the related tests from comment 0 have been updated and work now. I assume there is nothing blocking you anymore?

There are still some tests that fail due to this, but I think we could update the tests to not use (0,0) instead.

Also when I had a look at the updated tests I saw that two different action chains are used, and I wonder why that is necessary and not a single action chain for all the pointer actions is used.

It is to wait for pointerover occur first before generating subsequent actions, which can make the test more stable and easier to understand and also debug.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

With the new wdspec test landed it's clear that Chrome based browsers behave differently than the spec, while Firefox and Safari are spec compliant and do not allow an initial pointer move to 0/0. We are going to discuss this topic in the monthly W3C meeting tomorrow.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We decided to not change the behavior of the pointerMove action. Also I filed a bug for chromedriver to get the misbehavior corrected.

Edgar, if you have problems updating the remaining tests please reach out to us. Otherwise I would go ahead and close this bug as Wontfix. Thanks.