1797215 - Send async "touch" events at the widget level instead of synthesized DOM events

Status: ASSIGNED

(Remote Protocol :: Agent, task, P2)

Description

[Dan Robertson (:dlrobertson)]

Many of the scrollend and overscroll event tests use touchScrollInTarget to trigger a scroll in a scrollable element. Use native touch events instead of DOM events to make it possible to use touchScrollInTarget-like patterns in tests.

Comment 1

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

Touch events are a special type of events so I assume this should be blocked on bug 1773393 instead.

Comment 2

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

Please note that with bug 1852243 we have a temporary workaround available that will work fine for layout folks to work towards the interop 2023 goals. As such we do not have to work on this feature in M8 anymore.

Comment 3

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

Note that for calculating the position relative to the top-level widget (browser), you can use the new LayoutUtils.rectToToplevelWidgetRect() helper method. This method allows you to get the target position based on local coordinates, even from within frames. Ensure that the device pixel ratio settings are applied before calling this method.

Comment 4

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

Actually we will try to get this bug done for M12 but decided to mark it as optional.

Comment 5

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

Attachment: WIP: Bug 1797215 - Update JSDoc for EventUtils.js.

Comment 6

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

Attachment: WIP: Bug 1797215 - [remote] Add support for touch widget events to Marionette and WebDriver BiDi.

Comment 7

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

WiP patches are attached to the bug. Most of the webdriver tests work fine with dispatching the touch events as widget events via the parent process. But there is a situation which always causes tests to fail:

When a touchstart event is dispatched for a content browsing context a registered event handler on the page doesn't fire, unless the pointer was explicitly moved to the top-right corner of the content browsing context before. Could it be that there is a problem with initial location of the touch pointer input source? Here a minimized example:

        touch_chain = self.marionette.actions.sequence("pointer", "pointer_01", { "pointerType": "touch"})
        touch_chain.pointer_move(0, 0)  # without this line no `touchstart` is emitted on the page
        touch_chain.pointer_down(button=0)
        touch_chain.perform()

It can as well be reproduced with the test test_move_to_fractional_position (whereby something else causes another issue so no pointermove event is emitted):

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/testing/web-platform/tests/webdriver/tests/classic/perform_actions/pointer_touch.py#130-161

Edgar, do you have an idea what could be wrong?

Comment 8

[Edgar Chen [:edgar]]

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

It can as well be reproduced with the test test_move_to_fractional_position (whereby something else causes another issue so no pointermove event is emitted):

https://searchfox.org/firefox-main/rev/1f43fe5ffadde0b6898daf607cabb3335dd75d6f/testing/web-platform/tests/webdriver/tests/classic/perform_actions/pointer_touch.py#130-161

Edgar, do you have an idea what could be wrong?

Per discussion in slack, the initial position of touch input source looks weird. Let me know if you encounter other issues.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Locally confirmed snap-fling-in-large-area.html (which is one of the introp-2026 tests) passed with D284832. Thanks!