Intermittent /webdriver/tests/bidi/input/perform_actions/pointer_touch.py | test_touch_pointer_properties_angle_twist - assert 0 == 20
Categories
(Remote Protocol :: WebDriver BiDi, defect, P5)
Tracking
(firefox-esr115 unaffected, firefox-esr128 disabled, firefox129 disabled, firefox130 disabled, firefox131 disabled)
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | disabled |
| firefox129 | --- | disabled |
| firefox130 | --- | disabled |
| firefox131 | --- | disabled |
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: intermittent-failure, test-disabled)
The given test is currently marked as expected fail since the commits from bug 1857222 landed.
It actually emits some touch events by specifying altitude_angle and azimuth_angle. In the expected events we check for the tiltX and tiltY property values and compare them, but both are 0.
Here the related lines of code:
https://searchfox.org/mozilla-central/rev/396a6123691f7ab3ffb449dcbe95304af6f9df3c/testing/web-platform/tests/webdriver/tests/bidi/input/perform_actions/pointer_touch.py#152-153,163-164,189-190
Masayuki, you recently landed a fix for bug 1656377 which touched that area. Should it be supposed to be working now? Or does that require further implementations?
| Reporter | ||
Updated•1 year ago
|
I don't touch the path to synthesize touch events for altitudeAngle and azimuthAngle.
https://searchfox.org/mozilla-central/rev/e51b2630b44a8836a7ff35a876a2d8b555041d4a/dom/base/nsDOMWindowUtils.cpp#849
Although the new properties will be computed from tiltX and tiltY automatically, but tiltX and tiltY values are required to synthesize touches, but I don't find the conversion from tilt[XY] to (altitude|azimuth)Angle.
https://searchfox.org/mozilla-central/rev/e51b2630b44a8836a7ff35a876a2d8b555041d4a/remote/shared/webdriver/Event.sys.mjs#154-155
The code still tries to synthesize a tap with altitudeAngle and azimuthAngle but without tiltX and tiltY. So, the tiltX and tiltY values should be set to 0 and specified altitudeAngle and azimuthAngle should not be set to the event.
| Reporter | ||
Comment 2•1 year ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)
The code still tries to synthesize a tap with
altitudeAngleandazimuthAnglebut withouttiltXandtiltY. So, thetiltXandtiltYvalues should be set to0and specifiedaltitudeAngleandazimuthAngleshould not be set to the event.
Thanks! So you are basically saying that when we want to synthesize a touch event by using altitudeAngle and azimuthAngle the tilt values need to be set to 0? What should happen if both types are specified? Has one a higher priority?
Also I just checked Actions.sys.mjs and I can only find the usage of the altitudeAngle and azimuthAngle for the pointer type. So we don't seem to even forward those values to EventUtils.sys.mjs at all at the moment. This might already be the reason but before planning any implementation I'ld like to appreciate an answer to the above question.
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #2)
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)
The code still tries to synthesize a tap with
altitudeAngleandazimuthAnglebut withouttiltXandtiltY. So, thetiltXandtiltYvalues should be set to0and specifiedaltitudeAngleandazimuthAngleshould not be set to the event.Thanks! So you are basically saying that when we want to synthesize a touch event by using
altitudeAngleandazimuthAnglethetiltvalues need to be set to0?
No, I think that they should not be set.
What should happen if both types are specified? Has one a higher priority?
For initializing trust events (i.e., representing user inputs), there is no definitions. I think that the spec editors do not assume that the values of these pairs of trusted events never inconsistent.
For untrusted events (i.e., generated by JS), specified values are used as-is. If only one value of each pair, the other values are initialized with their default values. Therefore, the pairs will be inconsistent.
As far as I've checked, WebDriver spec does not solve this issue, but I found a spec issue. So I think that if both pairs' values are specified, GeckoDriver should return error and compute tiltX and tiltY from altitudeAngle and azimuthAngle if only the latter(s) is specified. The C++ code has conversion methods in widget/MouseEvents.h. So I think that there should be another nsIDOMWindowUtils method to synthesize touched without tiltX and tiltY to save the maintenance cost.
Description
•