1918049 - Several wpt input event tests are failing because of setup issues with the frame and invalid usage of the test_driver API

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P2)

Description

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

Tests are failing across browsers due to several reasons:

• Not waiting for iframe to be loaded causing the input element not being present (searchfox)
• Invalid usage of test_driver_internal (searchfox)

While using a keyboard for one of the tests will work fine with the test_driver, we cannot use test_driver.click nor test_driver_internal.click because this implementation is currently broken. It doesn't forward the user defined x and y values as expected. As such we need to use the Action implementation to issue the click on the input element.

Not sure why but this started to fail permanently when I landed my patch for bug 1904665. So I'll take a look and get these tests fixed.

Comment 1

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

The click case looks kinda suspicious. When calculating the target coordinates for the mouse click I get completely different results for Firefox. While Chrome has [131, 4] and Safari has [132, 4] the target for Firefox is [183, 14]. This is by using the following code:

    const x = inputElement.offsetLeft + inputElement.offsetWidth - 14;
    const y = inputElement.offsetTop + Math.round(inputElement.offsetHeight / 4);

    const actions = new test_driver.Actions()
      .setContext(frame.contentWindow)
      .pointerMove(x, y)
      .pointerDown()
      .pointerUp();
    await actions.send();

I assume that something is wrong with Firefox's implementation here given that Chrome and Safari are close and it can be a rounding issue.

Comment 2

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

Updating the style for the input element to have a fixed width and height makes it actually easier to compare because each browser has different default values for both. By using a width of 100px and a height of 20px I see a mousemove action generated with [94, 13] for each browser. Nevertheless the results are different. The generated mouse event differs:

Firefox: 94, 13
Chrome: 84, 3
Safari: 84, 3

The difference of 10px for both x and y comes from the margin of the body, which is 8px, and 2px for the border of the frame.

When I read the WebDriver specification correctly for get coordinates relative to an origin it should take both the x and y values as is when the origin is of type viewport. Not sure why Safari and Chrome subtract the outer offset here.

Comment 3

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

James, do you think that this is an issue with our implementation? I don't feel so given that the coordinates of the mouse events that we get in the iframe are actually the ones that we use when synthesizing the event.

Comment 4

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

Trying to fix the test for preventDefault shows another problem in Firefox (and Safari) while it works for Chrome.

When using the keyboard to enter a number the input is prevented and no input and change events are fired. But I can still use the arrow keys and the spin buttons to actually increase and decrease the numbers. Here the input doesn't get prevented. When reading a bit through bug 946390 I feel that this should be prevented and as such is a bug in Firefox. Jonathan, could you please check? I did a search but cannot find an open bug. Thanks!

Comment 5

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

FYI the tests were originally added around 3 months ago via https://github.com/web-platform-tests/wpt/pull/46561.

Comment 6

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

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

Trying to fix the test for preventDefault shows another problem in Firefox (and Safari) while it works for Chrome.

When using the keyboard to enter a number the input is prevented and no input and change events are fired. But I can still use the arrow keys and the spin buttons to actually increase and decrease the numbers. Here the input doesn't get prevented. When reading a bit through bug 946390 I feel that this should be prevented and as such is a bug in Firefox. Jonathan, could you please check? I did a search but cannot find an open bug. Thanks!

I chatted with Olli and it looks like that Chrome updated its behavior recently. So that's why it works. I've filed bug 1918254 to follow-up with a fix for DOM.

Comment 7

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

Attachment: Bug 1918049 - [wpt] Fix several input events spin button and arrow key tests for broken setup and test driver usage.

Comment 8

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

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

Firefox: 94, 13
Chrome: 84, 3
Safari: 84, 3

The difference of 10px for both x and y comes from the margin of the body, which is 8px, and 2px for the border of the frame.

When I read the WebDriver specification correctly for get coordinates relative to an origin it should take both the x and y values as is when the origin is of type viewport. Not sure why Safari and Chrome subtract the outer offset here.

This is indeed a problem with Chrome and Safari. I've created a WebDriver test over on https://github.com/web-platform-tests/wpt/pull/48123 which demonstrates that misbehavior.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae1bf54a9000
[wpt] Fix several input events spin button and arrow key tests for broken setup and test driver usage. r=masayuki

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/48147 for changes under testing/web-platform/tests

Comment 11

[Cristian Tuns]

Backed out for causing wpt failures in input-events-get-target-ranges-joining-dl-elements.tentative.html

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-NOTRUN | /input-events/input-events-get-target-ranges-joining-dl-elements.tentative.html?Backspace | Backspace at "<dl><dd>list-item1[</dd></dl><dl><dd>list-item2]</dd><dd>list-item3</dd></dl>" - expected FAIL
  TEST-UNEXPECTED-NOTRUN | /input-events/input-events-get-target-ranges-joining-dl-elements.tentative.html?Backspace | Backspace at "<dl><dd>[list-item1</dd></dl><dl><dd>list-item2]</dd><dd>list-item3</dd></dl>" - expected FAIL

Comment 12

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

The failures are caused by the additional patches from bug 1904665. So I'll land the fixes for this bug separately now.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7ef47fdb8c54
[wpt] Fix several input events spin button and arrow key tests for broken setup and test driver usage. r=masayuki

Comment 14

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/7ef47fdb8c54

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot