198129 2019-05-22 10:26:19 -0700 REGRESSION: Layout Test scrollbars/overflow-custom-scrollbar-crash.html is flaky 2019-05-23 12:11:18 -0700 1 1 1 Unclassified WebKit Tools / Tests WebKit Nightly Build Unspecified Unspecified RESOLVED CONFIGURATION CHANGED https://bugs.webkit.org/show_bug.cgi?id=198177 https://bugs.webkit.org/show_bug.cgi?id=198178 https://bugs.webkit.org/show_bug.cgi?id=198191 InRadar P2 Normal --- 1 tsavell webkit-unassigned graouts ryanhaddad simon.fraser sroberts webkit-bug-importer oldest_to_newest 1538250 0 tsavell 2019-05-22 10:26:19 -0700 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 1538251 1 tsavell 2019-05-22 10:28:58 -0700 Due to a lack of builds I have a regression range of 245563 — 245594. most of these are cherry picks and can be disregarded 1538288 2 tsavell 2019-05-22 11:22:55 -0700 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. 1538290 3 webkit-bug-importer 2019-05-22 11:24:55 -0700 <rdar://problem/51034859> 1538629 4 graouts 2019-05-23 03:43:29 -0700 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. 1538632 5 graouts 2019-05-23 05:08:48 -0700 (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. 1538639 6 graouts 2019-05-23 05:40:42 -0700 (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. 1538695 7 ap 2019-05-23 10:56:25 -0700 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. 1538720 8 graouts 2019-05-23 11:17:32 -0700 This is fixed now that the commits for 198177 and 198178 have landed. 1538726 9 graouts 2019-05-23 11:36:31 -0700 (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. 1538734 10 ap 2019-05-23 11:45:07 -0700 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. 1538741 11 graouts 2019-05-23 12:11:18 -0700 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.