After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 615451 - Tooltips stick when switching desktops using compiz
Tooltips stick when switching desktops using compiz
Product: gtk+
Classification: Platform
Component: Widget: Other
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2010-04-11 13:58 UTC by Cornwall
Modified: 2018-05-02 14:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

Patch which makes sure tooltips don't display after LeaveNotify (451 bytes, patch)
2010-04-12 16:32 UTC, Johan Tavelin
none Details | Review
Updated patch (1.44 KB, patch)
2010-05-15 22:14 UTC, Johan Tavelin
none Details | Review
program which changes the tooltip of a button once every second (3.74 KB, text/x-csrc)
2010-06-01 20:28 UTC, Johan Tavelin
program which sleeps for five seconds, grabs the pointer, sleeps for another five seconds and then quits (905 bytes, text/x-csrc)
2010-06-01 20:29 UTC, Johan Tavelin

Description Cornwall 2010-04-11 13:58:05 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:
Comment 1 Vish 2010-04-12 11:45:43 UTC
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."
Comment 2 Johan Tavelin 2010-04-12 16:32:26 UTC
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.
Comment 3 Cody Russell 2010-04-14 20:50:22 UTC
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?
Comment 4 Johan Tavelin 2010-05-15 22:14:54 UTC
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.
Comment 5 Matthias Clasen 2010-06-01 18:12:09 UTC
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.
Comment 6 Johan Tavelin 2010-06-01 20:28:22 UTC
Created attachment 162497 [details]
program which changes the tooltip of a button once every second
Comment 7 Johan Tavelin 2010-06-01 20:29:06 UTC
Created attachment 162498 [details]
program which sleeps for five seconds, grabs the pointer, sleeps for another five seconds and then quits
Comment 8 Johan Tavelin 2010-06-01 20:30:17 UTC
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.
Comment 9 Renzo Bagnati 2010-08-10 20:18:59 UTC
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:
I've been using them for months without problems and had positive feedbacks from other users also.
Comment 10 Paul Smith 2010-09-28 13:47:39 UTC
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.
Comment 11 Tobias Mueller 2017-02-18 10:33:13 UTC
FTR: People seem to have issues with gtk's behaviour here:

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
Comment 12 GNOME Infrastructure Team 2018-05-02 14:56:13 UTC
-- 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: