Bug 198129 – REGRESSION: Layout Test scrollbars/overflow-custom-scrollbar-crash.html is flaky

• Component: Tools / Tests
• Status: RESOLVED CONFIGURATION CHANGED

[Truitt Savell]

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

[Truitt Savell]

Due to a lack of builds I have a regression range of 245563 — 245594. most of these are cherry picks and can be disregarded

[Truitt Savell]

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.

[Radar WebKit Bug Importer]

<rdar://problem/51034859>

[Antoine Quint]

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.

[Antoine Quint]

(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.

[Antoine Quint]

(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.

[Alexey Proskuryakov]

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.

[Antoine Quint]

This is fixed now that the commits for 198177 and 198178 have landed.

[Antoine Quint]

(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.

[Alexey Proskuryakov]

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.

[Antoine Quint]

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.