Open Bug 1913696 Opened 1 year ago Updated 1 year ago

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)

defect

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?

Flags: needinfo?(masayuki)

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.

Flags: needinfo?(masayuki)

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

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.

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 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.

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?

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.

You need to log in before you can comment on or make changes to this bug.