The following layout test is failing on GTK fast/events/touch/frame-hover-update.html --- /home/charlie/git/WebKit/WebKitBuild/Debug/layout-test-results/fast/events/touch/frame-hover-update-expected.txt +++ /home/charlie/git/WebKit/WebKitBuild/Debug/layout-test-results/fast/events/touch/frame-hover-update-actual.txt @@ -6,15 +6,15 @@ PASS hoveredTop.length is 1 PASS hoveredIframe1.length is 0 PASS hoveredIframe2.length is 1 -PASS hoveredTop.length is 0 +FAIL hoveredTop.length should be 0. Was 1. PASS hoveredIframe1.length is 0 -PASS hoveredIframe2.length is 0 +FAIL hoveredIframe2.length should be 0. Was 1. PASS hoveredTop.length is 1 PASS hoveredIframe1.length is 0 -PASS hoveredIframe2.length is 0 +FAIL hoveredIframe2.length should be 0. Was 1. PASS hoveredTop.length is 1 PASS hoveredIframe1.length is 0 -PASS hoveredIframe2.length is 0 +FAIL hoveredIframe2.length should be 0. Was 1. PASS successfullyParsed is true TEST COMPLETE Probable cause: Unknown, it appears to have started crashing in one of r217970, r217971 or r217972 It seems like r217971 is most likely, as r217970 was specific to WPE, and r217972 doesn't seem like it could have caused such a regression. But I'm not sure.
And by crashing I actually meant failing!
(In reply to Charlie Turner from comment #1) > And by crashing I actually meant failing! Can we have a backtrace for the crash?
Sorry, I was trying to correct myself above, this wasn't a crash, just a failure.