Bug 326201 – [GTK] Hover state stays stuck when the pointer leaves the view on Wayland (GTK3)

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Mariyan Borisov]

On Wayland, a GTK3 WebKitWebView usually keeps the element under the pointer hovered after the pointer has left the window. No mouseout or mouseleave is dispatched, and :hover stays applied until the pointer comes back.

Steps to reproduce (in a Wayland session; test page attached):
1. MiniBrowser hover-leave.html
2. Move the pointer onto the grey box, which turns orange.
3. Move the pointer out of the window through its left, right or bottom edge in one quick movement.

Expected: the box turns grey again and its mouseleave counter goes up.
Actual: the box stays orange until the pointer comes back into the view.

wl_pointer.leave has no position, so GTK3 fills the leave-notify event with the last known pointer position (pointer_handle_leave() in gdk/wayland/gdkdevice-wayland.c), which is still inside the view. webkitWebViewBaseCrossingNotifyEvent() only corrects positions that are less than 1px outside an edge (the rounding case its comment describes), and WebEventFactory turns the leave into a mouse move at that position. The web process hit-tests the same element again, so mouseout is never dispatched.

GTK4 doesn't have this problem. Its leave signal has no position at all, so webkitWebViewBaseLeave() uses a point 1px outside the edge closest to the last known pointer position (that edge choice came in with bug 238327). The GTK3 handler still uses the position from the event.

How often it happens depends on the window. When the view reaches the edge of the window's surface (for example with server-side decorations on KDE), every exit I tried was missed, slow or fast. With client-side decorations (a GtkHeaderBar), slow exits cross GTK's own resize border first, so GTK sees a real position and they were noticed (8 of 8), but quick exits still weren't (0 of 15 single moves, 2 of 8 two-move exits noticed). It also happens under XWayland (GDK_BACKEND=x11), apparently because XWayland also reports the last position inside the window.

Measured with WebKitGTK 2.54.0 on Fedora 44 (KDE Plasma 6.7) in a plain GTK3 window whose web view fills it, pointer moved with ydotool:
- Wayland: 0 of 41 exits noticed (25 single 120px moves through all four edges, including 5 out of an iframe; 8 exits made of two quick 40px moves; 8 slow exits in 2px steps).
- XWayland: 0 of 26.
- With the proposed fix, which applies the GTK4 logic to GTK3 leave events: 41 of 41 and 26 of 26, and moving back in fires mouseenter again.
- The same fix on WebKit main (GTK3 build): 26 of 26 exits noticed, against 0 of 26 without it.
- Two web views side by side in one window: moving from one into the other was noticed with and without the fix (GTK makes up that crossing from a real motion event); leaving the window from the second view was missed 3 of 3 without the fix and noticed 3 of 3 with it.

Cases the fix leaves alone gave identical results with and without it: the context menu (including moving the pointer out while it is open), a <select> popup, dragging the scrollbar out of the window and releasing it outside (no scroll jump), drag and drop out of the window, and pressing a button, leaving and releasing outside. Unlike the GTK4 handler, the fix skips crossing events caused by grabs (any mode other than GDK_CROSSING_NORMAL), so hover behaves as today while a menu is open. That condition can go if you'd rather match GTK4 exactly.

The fix comes with an API test (/webkit/WebKitWebView/mouse-leave-with-position-inside) that sends a leave event with a position inside the view, like GDK does on Wayland. On main it passes with the fix and fails without it (3 of 3 runs each). I ran it on a release build with the four private test helpers exported, because release builds hide them.

[Mariyan Borisov]

Created attachment 481654 [details]
Test case (MiniBrowser)

[Mariyan Borisov]

Created attachment 481655 [details]
The same test in a plain GTK 3 window (Python)

[Mariyan Borisov]

Created attachment 481656 [details]
Screenshot: 2.54.0 and 2.54.0 with the fix, after a quick exit

Screenshot of the Python test on Fedora 44 (KDE Plasma 6.7, Wayland), taken after the pointer left the window in one quick movement. Left: WebKitGTK 2.54.0, where the box is still hovered and no mouseleave was dispatched. Right: 2.54.0 with the proposed fix.

[Mariyan Borisov]

Pull request: https://github.com/WebKit/WebKit/pull/75771

[EWS]

Committed 322821@main (e3f3f4f68d99): <https://commits.webkit.org/322821@main>

Reviewed commits have been landed. Closing PR #75771 and removing active labels.