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 752076 - [gtk2] Tooltips don't disappear when window looses focus
[gtk2] Tooltips don't disappear when window looses focus
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-07-07 13:29 UTC by Christian Stadelmann
Modified: 2018-02-10 09:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Stadelmann 2015-07-07 13:29:16 UTC
Affected Gtk Widgets:
* GtkTreeView
* GtkStatusIcon
* GtkTable
* GtkEntry (especially GtkSearchEntry)
* composite widget GtkFileChooser (list on the left, table on the right)
* tool palette
* GtkSpinner (e.g. in GtkColorChooser dialog)
* …

Not affected Gtk Widgets:
* GtkButton (and its subclasses like GtkToggleButton, GtkCheckButton, …)
* …

Affected applications (examples):
geany
* left pane: Symbols, Documents, Files
Zim desktop wiki:
* status icon, left pane
gtk2 demo application (obviously)

Steps to reproduce:
1. open any affected application
2. find an affected widget
3. hover until tooltip appears, keep mouse there (don't move)
4. change window focus by keyboard, e.g.:
a) press super key to open gnome-shell activities overview
b) press super+tab or super+[key above tab]
c) invoke a global key combination to start another application

What happens:
If the new application gaining focus is a gtk3 or qt4 application (must not be gtk2) the tooltip is still visible. It will stay visible until either
a) mouse moves over the tooltip
b) mouse moves over the gtk2 application
c) gtk2 application exits
d) gtk2 applications gains focus again

What is expected to happen:
Applications should not display tooltips above windows of other applications

Additional info:
This issue is not present when using alt+tab instead of super+tab. It also doesn't happen when using the default gnome-shell keybinding for changing to another workspace, ctrl+alt+arrow.
This issue affects gtk2 applications, but not gtk3 applications. It is present on both gnome-shell+X and gnome-shell+wayland.

Package versions (Fedora 22):
gtk2-2.24.28-1.fc22.x86_64
gtk3-3.16.4-2.fc22.x86_64
gnome-shell-3.16.3-1.fc22.x86_64
mutter-3.16.3-1.fc22.x86_64

Related issues:
https://bugzilla.gnome.org/show_bug.cgi?id=102283 (win32, mouse focus)
https://bugzilla.gnome.org/show_bug.cgi?id=460011 (gtk2, status icon)
Comment 1 Matthias Clasen 2015-07-08 02:54:03 UTC
tooltips are not supposed to disappear when an application looses focus. they are tied to whether the pointer rests over the active area or not.

tooltips can and should appear above windows of other applications if the geometry requires it.
Comment 2 Matthias Clasen 2015-07-08 17:48:56 UTC
there might still be bugs of course, where we tooltips get unintentionally left behind
Comment 3 Christian Stadelmann 2015-07-11 15:14:02 UTC
(In reply to Matthias Clasen from comment #1)
> tooltips are not supposed to disappear when an application looses focus.
> they are tied to whether the pointer rests over the active area or not.

It's not about that. Sorry, it looks like I didn't explain it good enough.
Lets say I have an application (geany) which displays a tooltip. Then I use Super+Tab to switch to another application, e.g. nautilus. The nautilus window covers the whole geany window. Nautilus especially covers the area in geany the tooltip belongs to. geany does not get any mouse focus, but it does not seem to get a "mouse focus lost" event on super+tab.

This is a case of tooltips getting left behind unintentionally.
Comment 4 Matthias Clasen 2015-07-11 15:38:05 UTC
I've tried, but so far I am not able to reproduce this. The only application with which I experience left-behind tooltips is firefox, which I believe uses its own, buggy tooltip implementation.
Comment 5 Christian Stadelmann 2015-07-11 22:17:04 UTC
Firefox is not affected by this issue. Maybe because I am using Fedora with Firefox build for gtk3.
Comment 6 Matthias Clasen 2018-02-10 05:14:48 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 7 Christian Stadelmann 2018-02-10 09:44:39 UTC
I cannot reproduce this with Zim (desktop wiki application, written in Gtk+ 2.x and Python) any more, which was the most prominent application showing this behavior. Let's close this bug report.