Several wpt input event tests are failing because of setup issues with the frame and invalid usage of the test_driver API
Categories
(Core :: DOM: Events, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox132 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
References
(Blocks 1 open bug)
Details
(Whiteboard: [webdriver:m12], [wptsync upstream])
Attachments
(1 file)
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.
|
Assignee | |
Comment 1•20 days ago
|
||
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.
|
|
Assignee | |
Comment 2•20 days ago
|
||
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.
|
|
Assignee | |
Comment 3•20 days ago
|
||
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.
|
|
Assignee | |
Comment 4•20 days ago
|
||
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!
|
|
Assignee | |
Comment 5•20 days ago
|
||
FYI the tests were originally added around 3 months ago via https://github.com/web-platform-tests/wpt/pull/46561.
|
|
Assignee | |
Comment 6•20 days ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #4)
Trying to fix the test for
preventDefaultshows 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
inputandchangeevents 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.
|
|
Assignee | |
Updated•20 days ago
|
|
|
Assignee | |
Comment 7•19 days ago
|
||
|
|
Assignee | |
Comment 8•19 days ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #2)
Firefox: 94, 13
Chrome: 84, 3
Safari: 84, 3The 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 originit should take both thexandyvalues as is when the origin is of typeviewport. 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.
|
|
Assignee | |
Updated•19 days ago
|
|
||
Comment 11•18 days ago
|
||
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
|
|
Assignee | |
Comment 12•18 days ago
|
||
The failures are caused by the additional patches from bug 1904665. So I'll land the fixes for this bug separately now.
|
||
Comment 13•18 days ago
|
||
|
||
Updated•18 days ago
|
|
|
||
Comment 14•18 days ago
|
||
| bugherder | ||
Description
•