The following layout test is flaky on MacOS WK1 scrollbars/overflow-custom-scrollbar-crash.html Probable cause: This test became flakey recently. The test does not fail when ran on its own. using the list of tests on the same test runner I was able to bisect down to 1 test that is causing the failure: pointerevents/mouse/pointerdown-prevent-default.html Running this test before scrollbars/overflow-custom-scrollbar-crash.html casques a 100% failure. I am able to reproduce it using command: rwt --root testbuild-245594 pointerevents/mouse/pointerdown-prevent-default.html scrollbars/overflow-custom-scrollbar-crash.html --child-processes 1 -1 Flakiness Dashboard: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=scrollbars%2Foverflow-custom-scrollbar-crash.html Diff: --- /Volumes/Data/slave/mojave-release-tests-wk1/build/layout-test-results/scrollbars/overflow-custom-scrollbar-crash-expected.txt +++ /Volumes/Data/slave/mojave-release-tests-wk1/build/layout-test-results/scrollbars/overflow-custom-scrollbar-crash-actual.txt @@ -1 +1,2 @@ +CONSOLE MESSAGE: line 100: TypeError: undefined is not an object (evaluating 'scroller.parentNode') This test should not crash
Due to a lack of builds I have a regression range of 245563 — 245594. most of these are cherry picks and can be disregarded
I was able to reproduce the failure on a checkout of 245585 but not on 245584. Looks like https://trac.webkit.org/changeset/245585/webkit is the cause of this flakiness.
<rdar://problem/51034859>
This caught two issues: 1. We consider mouseover to a compatibility mouse event, but it isn't. 2. We still account for the fact that preventDefault() was called during handling of a "pointerdown" event even after the mouse is no longer pressed.
(In reply to Antoine Quint from comment #4) > This caught two issues: > > 1. We consider mouseover to a compatibility mouse event, but it isn't. This is tracked by https://bugs.webkit.org/show_bug.cgi?id=198177.
(In reply to Antoine Quint from comment #4) > This caught two issues: > > 2. We still account for the fact that preventDefault() was called during > handling of a "pointerdown" event even after the mouse is no longer pressed. This is tracked by https://bugs.webkit.org/show_bug.cgi?id=198178.
Out of curiosity, what was the mechanism that made pointerdown-prevent-default.html break a subsequent test? Generally, this is not something that I would expect to happen in DOM event test cases.
This is fixed now that the commits for 198177 and 198178 have landed.
(In reply to Alexey Proskuryakov from comment #7) > Out of curiosity, what was the mechanism that made > pointerdown-prevent-default.html break a subsequent test? > > Generally, this is not something that I would expect to happen in DOM event > test cases. A flag was set inside WebCore’s PointerCaptureController while handling pointerdown and it was not cleared on pointerup. The next test that runs starts off with the PointerCaptureController in a bad state, just like another interaction within that first test would have been a bad state, which is that the tests I’ve added check.
Thank you! Does either of the fixes make it so that the bit gets reset on navigation? Even if a navigation happens between pointerdown and pointerup, we don't want the old pointerdown to affect anything in the new page. I do not see anything navigation related in the fixes.
No, (In reply to Alexey Proskuryakov from comment #10) > Thank you! > > Does either of the fixes make it so that the bit gets reset on navigation? > Even if a navigation happens between pointerdown and pointerup, we don't > want the old pointerdown to affect anything in the new page. I do not see > anything navigation related in the fixes. No, the PointerCaptureController is not called into during navigation as far as I know. It's entirely possible that something else does though, but this requires testing. Raised https://bugs.webkit.org/show_bug.cgi?id=198191 to track this.