GNOME Bugzilla – Bug 615451
Tooltips stick when switching desktops using compiz
Last modified: 2018-05-02 14:56:13 UTC
Using the workspace switcher will cause a tooltip to stick in the corner until moused over again. This comment has an explanation and patch: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/356702/comments/52
Comment Cornwall mentions in lp ,by Johan Tavelin: "I have investigated this problem and found that the bug is in the tooltip code in gtk. When compiz switches workspace it performs a pointer grab and gtk tooltips don't handle this correctly. The following sequence of events will trigger the bug: 1) While a tooltip is displayed another program performs a pointer grab (e.g. using XGrabPointer). 2) The pointer grab triggers a LeaveNotify event and the tooltip is hidden. 3) The tooltip text is updated by the program and as the pointer still hovers the widget gtk displays the new updated tooltip. 4) The user moves the pointer away from the gtk widget while the pointer grab is still active. As the window has already received a LeaveNotify event it will not receive another one and the tooltip will stay on the screen. I have modified the gtk tooltip code so that a tooltip is not displayed if the widget window is not the same one as the one gdk thinks is the current window under the pointer. This appears to have solved the problem for me at least."
Created attachment 158503 [details] [review] Patch which makes sure tooltips don't display after LeaveNotify This is the patch that I attached to the launchpad bug report.
GdkDisplay->window_at_pointer doesn't seem like it's really meant to be public API. I wonder if gdk_display_get_window_at_pointer() might work here?
Created attachment 161139 [details] [review] Updated patch No, gdk_display_get_window_at_pointer() would not work. The reason why I used display->pointer_info.window_under_pointer was that it is updated based on enter and leave notify events. gdk_display_get_window_at_pointer() returns the window currently under the pointer even if leave notify has been sent. But I guess you are right in that the field is not supposed to be used. So I have rewritten the patch so that leave notify events are tracked in the tooltip code instead.
This appears to be a firefox-specific issue ? In my tests, I can only get firefox to leave a tooltip behind like that. I don't think the patch is right. Looking at send_event here is not a good idea; we generate enter/leave events internally for other reasons. What I would like to see here first is a reproducer, ie some test app that shows the same misbehaviour as firefox, but without the gobs of mozilla code.
Created attachment 162497 [details] program which changes the tooltip of a button once every second
Created attachment 162498 [details] program which sleeps for five seconds, grabs the pointer, sleeps for another five seconds and then quits
This does not only happen in firefox. The program which I have had the most problem with because of this bug is the workspace switcher in the gnome panel. I have attached two test applications which can be used to reproduce the bug. gtktest-tooltip - program which changes the tooltip of a button once every second x11test-grabpointer - program which sleeps for five seconds, grabs the pointer, sleeps for another five seconds and then quits. To reproduce the bug with these application do the following: 1) Start both applications 2) Move the pointer to the "Hello World" button to make the tooltip appear 3) Wait for first sleep in x11test-grabpointer to timeout 4) Now the tooltip will disappear for a short time and then reappear because of the tooltip change 5) Move the pointer away from the gtktest-tooltip window (do this before the x11test-grabpointer application has quit) 6) The tooltip will remain on the screen until gtktest-tooltip window receives another event The place where gtk behaves incorrectly is in step 4. Changing the tooltip text shouldn't cause the tooltip to reappear (as there would be no guarantee that it would ever disappear because the pointer grab is causing the gtk window to not receive any events). The reason why the tooltip do appear is because gtk_tooltip_trigger_tooltip_query simulates a motion event to update the tooltip. One way to fix this is to make sure that tooltips don't display if leave notify was the last event which was received by the tooltip code. This is what I tried to do in my patch. The reason why I used send_event is that the code which keeps track of events shouldn't consider the simulated events from gtk_tooltip_trigger_tooltip_query. I can also imagine that the tooltips sticking bug can appear when simulated events are sent to the window using other methods (e.g. with XSendEvent) so I thought send_event made sense to keep track of this.
I confirm that the bug is present with firefox and other applications. Moreover I get persistent tooltips also when switching with the window list applet, not only with the workspace switcher. I have made gtk+2.0 packages with the patch made by Johan Tavelin in a ubuntu ppa: https://launchpad.net/~renbag/+archive/ppa I've been using them for months without problems and had positive feedbacks from other users also.
Can someone please apply Johan's patch or else comment on why it's not appropriate so it can be improved? This bug has existed for at least 2 years and although it seems minor it's really stunningly annoying. As Johan says it happens most often with workspace switcher and for whatever reason I get this probably 2-3 times an hour on my desktop. When the tooltip is large, which it can be if the window title is long, it covers up enough of my window at the lower left to be very annoying. It also covers the left side of the window list applet on my panel, and that is very annoying as well. I have to take my hand off the keyboard again and move my mouse down over the tooltip to make it go away.
FTR: People seem to have issues with gtk's behaviour here: https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032608.html TL;DR: gtk-2 tooltips interfere with gdk_keyboard_grab in some window managers, recommend disabling tooltips. I recently upgraded from pinentry 0.9.7 to pinentry 1.0.0, using the gtk+-2 frontend, and was very surprised to have it break on me in a strange way: the window would appear and disappear. It also still seemed to be present in master (as of cd7b35e8ff) I use a tiling WM, Awesome, so I've seen similar glitches in the past for windows that wanted to steal focus. Reproducable via: $ pinentry-gtk-2 <<< "GETPIN" ** (pinentry-gtk-2:10527): CRITICAL **: could not grab keyboard: not viewable (3) ** (pinentry-gtk-2:10527): WARNING **: it took 4097 tries to grab the keyboard ** (pinentry-gtk-2:10527): WARNING **: it took 233 tries to grab the pointer
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/339.