1947721 - Missing "pointermove" events when performing a single pointer move action for input source of type "touch"

Status: RESOLVED INVALID

(Remote Protocol :: Agent, defect)

Description

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

The following WebDriver test fails in Firefox because not a single pointermove event is recognized (and added to the events list):

def test_move_to_position(session, inline, touch_chain):
    session.url = inline("""
        <script>
          var allEvents = { events: [] };
          window.addEventListener("pointermove", ev => {
            allEvents.events.push({
                "type": event.type,
                "pageX": event.pageX,
                "pageY": event.pageY,
            });
          }, { once: true });
        </script>
        """)

    target_point = {
        "x": 20,
        "y": 40,
    }

    touch_chain \
        .pointer_move(target_point["x"], target_point["y"]) \
        .perform()

    events = get_events(session)
    assert len(events) == 1

    assert events[0]["type"] == "pointermove"
    assert events[0]["pageX"] == 20
    assert events[0]["pageY"] == 40

I tried with Chrome and it fails as well, but with Safari the test is passing as expected.

I checked if we maybe miss to actually synthesize the event but I can say that we call into win.windowUtils.sendTouchEvent() as usual and the arguments are correct.

Masayuki, may you have an idea what's wrong in that case? Why don't we get a pointermove event? Using an input source type of mouse the test works fine. Could there be a bug in sendTouchEvent()?

Note that when I add a pointer down action before like the following it starts to work:

        touch_chain \
            .pointer_down(button=0) \
            .pointer_move(target_point["x"], target_point["y"]) \
            .perform()

I assume it should not be required to send a pointer down first before being able to receive pointer move events.

Comment 1

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

As discussed on Matrix with James it looks like that the initial pointer_down action actually means that we touch the surface, which is basically required to see any pointer move event. So the above would make sense. Now I just wonder how a real click could then be simulated like for the following case:

1. Touch the surface
2. Simulate a pointer move to a given position on the web page
3. Simulate an actual click on the element beneath the current pointer position

We cannot send pointer_down() twice for this purpose. Maybe a pointer_up() will trigger a click but what about the scenario when the pointer only needs to be moved to the element and then the contact to the surface is lost? How can this be simulated?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Right. At pointerdown, the pointerId becomes active if the device is handled as touch. Therefore, pointermove won't be fired if its pointerId is not active and its type is touch.

And yes, a single tap, pointerdown and pointerup only when there is no active touch pointer causes a set of compatible mouse events, like mousemove, mousedown, mouseup, then, click will be fired if the preceding mousedown is not consumed.

So, #1 can be emulated with pointer_down, #2 can be emulated with a pointer_move, then, pointer_up may cause a click on the common ancestor of pointer_down and pointer_up positions.

I think that you want to specify the position of pointer_down in this case. I'm not familiar with WebDriver, but TestDriver of WPT can do that with pointerMove before pointerDown. The pointerMove does not cause pointermove if the type is touch, but the internal pointer position is moved there. Then, pointerdown will be fired on the element underneath the last pointerMove destination.

Comment 3

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

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #2)

I think that you want to specify the position of pointer_down in this case. I'm not familiar with WebDriver, but TestDriver of WPT can do that with pointerMove before pointerDown. The pointerMove does not cause pointermove if the type is touch, but the internal pointer position is moved there. Then, pointerdown will be fired on the element underneath the last pointerMove destination.

Yes, that is what is already done in the WebDriver implementation. My confusion was only about the initial pointermove event before synthesizing any pointerdown event. So that has been clarified now and basically renders this bug as invalid. Thanks!