GNOME Bugzilla – Bug 765065
Wayland: Hover state stuck after mouse leaving the toplevel
Last modified: 2016-04-19 08:02:26 UTC
Created attachment 326030 [details] Video showing the issue Not sure if this is a gtk+ or a gnome-shell issue, but sometimes when I leave a window with the mouse, the hover state is stuck on a widget, causing it to look like it's :hover'ed or even showing the tooltip after the mouse has already left the toplevel. It seems like this mostly happens when I move the mouse fast, but it's not always reproducible. Video showing the issue attached, with gtk+ 3.20.3, gnome-shell 3.20.1 and mutter 3.20.1
Note: I can also reproduce this in weston.
Interesting, afaics (using GDK_DEBUG=events) the surface "leave" event is delivered by the gdk wayland backend when this happens.
Seems probably down to the interpretation of crossing mode/detail in GDK.
I suspect it might be a regression in 3.20 because I really cannot reproduce in 3.18. Can you?
Hmm, yeah, that's a good point. I don't remember this with 3.18 indeed.
Created attachment 326246 [details] [review] wayland: Do not check the pointer focus when receiving wl_pointer.frame The frame event is also meant to compress wl_pointer.leave events, at this point the focus surface will be definitely NULL. In the end, wl_pointer.frame should flush the last composed event despite the pointer focus.
So... AFAICT this should be happening with 3.18 too, the tablet branch reshuffled this code, but it seems this was previously present.
Yeap, looks like attachment 326246 [details] [review] fixes the issue for me :)
Thanks for confirming :), pushed. Attachment 326246 [details] pushed as bfcd9a2 - wayland: Do not check the pointer focus when receiving wl_pointer.frame
Can we get this into gtk-3-20 as well?