Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 4f26424a46878917878398a57d9a63172c2d2c81
https://github.com/WebKit/WebKit/commit/4f26424a46878917878398a57d9a63172c2d2c81
Author: Wenson Hsieh <wenson_hs...@apple.com>
Date: 2023-07-28 (Fri, 28 Jul 2023)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm
Log Message:
-----------
REGRESSION (266341@main): mousemove no longer dispatched when UI-side
compositing is disabled
https://bugs.webkit.org/show_bug.cgi?id=259618
Reviewed by Aditya Keerthi.
After the changes in 266341@main, when UI-side compositing is disabled, we can
end up in a state where mouse events are
indefinitely queued in the UI process, as the web process never flushes the
deferred DidReceiveEvent message for a
mousemove event that has already been handled. This is because
`TiledCoreAnimationDrawingArea::scheduleRenderingUpdate`
is unimplemented, and so nothing guarantees that we'll eventually send the
deferred `DidReceiveEvent` back to the UI
process.
Fix this by avoiding the deferred `DidReceiveEvent` if
`scheduleRenderingUpdate()` returns `false` (indicating that no
rendering update is scheduled). In practice, this effectively disables the
changes in 266341@main unless we're using a
remote layer tree drawing area, which is now the default on both macOS Sonoma
(in most device models) and iOS 17, which
enable UI-side compositing.
Test: MouseEventTests.SendMouseMoveEventStream
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::mouseEvent):
* Tools/TestWebKitAPI/Tests/mac/MouseEventTests.mm:
Canonical link: https://commits.webkit.org/266411@main
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
