1856991 - Using a "touch" click does not emit events internally as touch

Status: NEW

(Remote Protocol :: Marionette, defect, P3)

Description

[Oliver Medhurst [:canadahonk]]

Not entirely sure, when doing a touch type click event with webdriver in a WPT test this check should not pass but does anyway.

Comment 1

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

Is there a specific wpt test that fails because of that? It would be nice to have an easy to reproduce test case.

Comment 2

[Oliver Medhurst [:canadahonk]]

Sure, sorry I forgot to send: https://github.com/web-platform-tests/wpt/blob/master/html/user-activation/activation-trigger-pointerevent.html?touch

Comment 3

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

Note that the test got an update recently:
https://hg.mozilla.org/mozilla-central/rev/e05bd3ca512cad5cc4bccbd8f75f951821d44431

Running it the click_event promise doesn't resolve and as such the await is causing a timeout. But interestingly this only happens with a build from a recent mozilla-central checkout. When using a build from last week the test Activation through touch pointerevent click instead fails, and I get an unexpected ok as overall result.

Might this be related? Did maybe something else change internally since then which could have caused this change in behavior? What should be the expected behavior of the test at the moment?

Comment 4

[Oliver Medhurst [:canadahonk]]

Running it the click_event promise doesn't resolve and as such the await is causing a timeout.

Likely related to Bug 1856688?

What should be the expected behavior of the test at the moment?

With the patch for Bug 1791079, it should pass (it does not). The code in the patch is fine afaik and it is webdriver related.

Comment 5

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

Thanks! I'll have a look once bug 1791079 is on central and I don't have to run a full build.

Comment 6

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

I've verified that we call into nsIDOMWindowUtils.sendTouchEvent() from event.synthesizeMultiTouch:

 0:11.92 pid:68609 1697037503758	Marionette	TRACE	Dispatching tick 1/3
 0:11.92 pid:68609 1697037503758	Marionette	DEBUG	Grouping action pointer touchTestPointer pointerMove
 0:11.92 pid:68609 1697037503758	Marionette	TRACE	 Dispatch PauseAction with 0 16
 0:11.92 pid:68609 1697037503758	Marionette	TRACE	Dispatch PointerMoveTouchActionGroup with
 0:11.92 pid:68609 1697037503759	Marionette	TRACE	moveOverTime start: 0,0 target: 640,126 duration: 16
 0:11.94 pid:68609 *** debug: touchmove
 0:11.94 pid:68609 1697037503783	Marionette	TRACE	Dispatching tick 2/3
 0:11.94 pid:68609 1697037503783	Marionette	DEBUG	Grouping action pointer touchTestPointer pointerDown
 0:11.94 pid:68609 1697037503783	Marionette	TRACE	 Dispatch PauseAction with 0 16
 0:11.94 pid:68609 1697037503783	Marionette	TRACE	Dispatch PointerDownTouchActionGroup with touchTestPointer
 0:11.94 pid:68609 *** debug: touchstart
 0:11.96 pid:68609 1697037503800	Marionette	TRACE	Dispatching tick 3/3
 0:11.96 pid:68609 1697037503800	Marionette	DEBUG	Grouping action pointer touchTestPointer pointerUp
 0:11.96 pid:68609 1697037503800	Marionette	TRACE	 Dispatch PauseAction with 0 16
 0:11.96 pid:68609 1697037503800	Marionette	TRACE	Dispatch PointerUpTouchActionGroup with touchTestPointer
 0:11.96 pid:68609 *** debug: touchend
 0:11.98 pid:68609 1697037503820	Marionette	DEBUG	2 <- [1,24,null,{"value":null}]

We also pass the checks for valid touch events in sendTouchEvent. So I assume we are sending the correct event.

As such I'm not sure why EventStateManager::PreHandleEvent thinks that the input source isn't touch.

Could it be a problem with the test or a platform issue?

Comment 7

[Oliver Medhurst [:canadahonk]]

Thanks for verifying. The tests are correct according to spec. I think there might be something deeper internally blocking/causing, but not sure what yet after looking around a bit more, sorry.

Comment 8

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

Olli, would you maybe have an idea what could be wrong here or an advice where to look at? See also my comment 6 where I verified that we are sending the correct events.

The command to run is:

./mach wpt --setpref="remote.log.level=Trace" /html/user-activation/activation-trigger-pointerevent.html?touch

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Which events are passed to synthesizeMultiTouch? And what all parameters?

Comment 10

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

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #9)

Which events are passed to synthesizeMultiTouch? And what all parameters?

See my comment 6. It's touchmove, touchstart, and touchend.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

And these prefs are enabled https://searchfox.org/mozilla-central/rev/5ad226c7379b0564c76dc3b54b44985356f94c5a/dom/base/nsDOMWindowUtils.cpp#938-939 ?

Comment 12

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

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #11)

And these prefs are enabled https://searchfox.org/mozilla-central/rev/5ad226c7379b0564c76dc3b54b44985356f94c5a/dom/base/nsDOMWindowUtils.cpp#938-939 ?

No, we do not dispatch async events via Marionette yet, and my patch for making async events default in wpt has also been backed out. So this is all about dispatching the touch events from the content process via EventUtils.

Comment 13

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

This is actually not working right now given that synthesizing touch events will not cause the browser to emit mouse specific events. This is all done by the APZ layer and we will have to wait for bug 1773393 (async event dispatching through the parent process) to be fixed.