Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e3f3f4f68d991d608839965102ea076b747ab212
https://github.com/WebKit/WebKit/commit/e3f3f4f68d991d608839965102ea076b747ab212
Author: Mariyan Borisov <[email protected]>
Date: 2026-10-06 (Tue, 06 Oct 2026)
Changed paths:
M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestUIClient.cpp
Log Message:
-----------
[GTK] Hover state stays stuck when the pointer leaves the view on Wayland
(GTK3)
https://bugs.webkit.org/show_bug.cgi?id=326201
Reviewed by Carlos Garcia Campos.
On Wayland, leave events carry no position, so GTK3 fills them with the last
known pointer position,
which is still inside the view. The leave then reaches the web process as a
mouse move inside the
view, and WebCore keeps the element under it hovered: no mouseout is
dispatched, and :hover stays
until the pointer comes back. The same happens with GTK3's X11 backend under
Xwayland when the
pointer moves from the view onto a Wayland window.
Move the code webkitWebViewBaseLeave() uses for GTK4 into
pointOutsideViewClosestTo(), and use it
for GTK3 too: when a normal, non-inferior leave has a position inside the view,
use a point 1px
outside the edge closest to that position instead. Crossing events caused by
grabs, such as a
context menu opening, keep the current behavior.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestUIClient.cpp
* Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:
(pointOutsideViewClosestTo):
(webkitWebViewBaseCrossingNotifyEvent):
(webkitWebViewBaseLeave):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestUIClient.cpp:
(UIClientTest::sendCrossingEventAndWaitUntilMouseTargetChanged):
(testWebViewMouseLeaveWithPositionInside):
(testWebViewMouseEnterAndLeaveWithoutMotion):
(beforeAll):
Canonical link: https://commits.webkit.org/322821@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
