Bug 223729
Summary: | REGRESSION(r 274381) [WPE] css3/scroll-snap/scroll-snap-wheel-event.html is flaky failing in release mode | ||
---|---|---|---|
Product: | WebKit | Reporter: | Lauro Moura <lmoura> |
Component: | UI Events | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | bugs-noreply, simon.fraser |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=222594 https://bugs.webkit.org/show_bug.cgi?id=234526 |
Lauro Moura
css3/scroll-snap/scroll-snap-wheel-event.html
Usually the first assertion fails, but occasionally the second one fails too. Modifying the test to print the actual values:
-PASS horizontalContainer.scrollLeft is 200
-PASS verticalContainer.scrollTop is 185
+FAIL horizontalContainer.scrollLeft should be 200. Was 0.
+FAIL verticalContainer.scrollTop should be 185. Was 200.
PASS successfullyParsed is true
+Some tests failed.
Checking the event dispatcher, the debug build ScrollingTree::determineWheelEventProcessing always returns in the isSynchronousDispatchRegion (~95) check when determining the processing steps for both events, thus handling the event in the main thread.
Meanwhile, in the Release build, most of the time, during the handling of the first event, the ScrollingTree's m_treeState.eventTrackingRegions is empty and the method returns only ScrollingThread in the processing steps. Rarely it has the same behavior as the debug build.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Simon Fraser (smfr)
I had to skip this test for Win and GTK in https://trac.webkit.org/changeset/287376/webkit because it times out; for some reaon WheelEventTestMonitor doesn't work as it does on macOS. The log channel would help diagnose.