[webkit-changes] [WebKit/WebKit] 4f2642: REGRESSION (266341 at main): mousemove no longer disp...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4f26424a46878917878398a57d9a63172c2d2c81
      https://github.com/WebKit/WebKit/commit/4f26424a46878917878398a57d9a63172c2d2c81
  Author: Wenson Hsieh <wenson_hsieh at 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 at 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 at 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 at 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