The main thread scroll event handling and latching logic has evolved over time and lacks a real design; see issues noted in bug 215741.
Created attachment 407545 [details] Patch
Created attachment 407551 [details] Patch
Created attachment 407553 [details] Patch
Created attachment 407554 [details] Patch
Comment on attachment 407554 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=407554&action=review > Source/WebCore/page/scrolling/ScrollLatchingController.cpp:55 > +// FIXME: This logic is different frmo ScrollingTreeLatchingController, which simply lets the latching state elapse after 100ms. frmo > Source/WebCore/page/scrolling/ScrollLatchingController.cpp:186 > + // We always allow the main frame receive wheel events to permit rubber-banding. Some grammar > Source/WebCore/page/scrolling/ScrollLatchingController.h:75 > + Frame* frame { nullptr }; // Icky raw pointer. Use FrameIdentifier? Did you want to fix this before landing? > Source/WebCore/page/scrolling/ScrollingTreeLatchingController.cpp:40 > static const Seconds resetLatchedStateTimeout { 100_ms }; Should we plop this in one place and use it from both? > Source/WebCore/platform/PlatformWheelEvent.h:155 > + bool isGestureContinuation() const; // The fingers-down part of the gesture. But not momentum? > LayoutTests/ChangeLog:14 > +2020-08-18 Simon Fraser <simon.fraser@apple.com> Double changelog
https://trac.webkit.org/r266333
<rdar://problem/68034254>
The mouse wheel doesn't scroll page in trunk@266333 for WinCairo WK1 and WK2. This change seems the culprit.
Fixed in bug 215990.