Bug 219255

Created attachment 414800 [details]
WIP patch

This patch applies on top of patch attached to bug #219024. It fixes the timeout in imported/w3c/web-platform-tests/pointerevents/pointerevent_attributes_hoverable_pointers.html and imported/w3c/web-platform-tests/pointerevents/pointerlock/pointerevent_pointermove_in_pointerlock.html

<rdar://problem/71802566>

Created attachment 415846 [details]
WIP patch

This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess

Created attachment 415849 [details]
WIP patch

Created attachment 415855 [details]
WIP patch

Created attachment 415871 [details]
Patch

The API test failure is unrelated.

Ping reviewers

Comment on attachment 415871 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=415871&action=review

> LayoutTests/imported/w3c/web-platform-tests/uievents/click/click_event_target_child_parent-expected.txt:11
> -PASS Click targets the nearest common ancestor
> +FAIL Click targets the nearest common ancestor assert_equals: Click should be sent to the nearest common ancestor expected "mousedown@link1,mouseup@link_container1,click@link_container1,mousedown@link_container2,mouseup@link2,click@link_container2" but got "mousedown@link1,mouseup@link_container1,mousedown@link_container2,mouseup@link2,click@link_container2"

Do you understand the cause of this one?

Comment on attachment 415871 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=415871&action=review

>> LayoutTests/imported/w3c/web-platform-tests/uievents/click/click_event_target_child_parent-expected.txt:11
>> +FAIL Click targets the nearest common ancestor assert_equals: Click should be sent to the nearest common ancestor expected "mousedown@link1,mouseup@link_container1,click@link_container1,mousedown@link_container2,mouseup@link2,click@link_container2" but got "mousedown@link1,mouseup@link_container1,mousedown@link_container2,mouseup@link2,click@link_container2"
> 
> Do you understand the cause of this one?

hmm, I don't remember, I'll investigate. I have follow up patches in my local branch, I'll check them too.

Comment on attachment 415871 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=415871&action=review

Mildly surprised this doesn't progress anything in infrastructure/, given that has a number of tests for testdriver like this. But this generally looks good to me, modulo the comments below (and Darin's one above).

> LayoutTests/imported/w3c/web-platform-tests/resources/testdriver-vendor.js:24
> +      let frames = document.getElementsByTagName("iframe");
> +      for (let i = 0; i < frames.length; i++) {

Would it not be better to use window.frames here? As it is, this only handles iframes and not framesets. (This is likely a marginal issue, but an easy fix.)

> LayoutTests/imported/w3c/web-platform-tests/resources/testdriver-vendor.js:68
> +                        let frame = findElementInFrame(action.origin, window);
> +                        if (!frame)
> +                            return Promise.reject(new Error("Pointer origin element in different document or iframe."));

Given `findElementInFrame` above recurses, this seems slightly unclear. Maybe "Pointer origin element not in this document or descendent document"? I'm not really happy with that either, though.