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 775462 - Hover or mouse move incorrectly or not reported or handled
Hover or mouse move incorrectly or not reported or handled
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: X11
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-12-01 12:21 UTC by Mikołaj Małecki
Modified: 2018-05-02 17:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mikołaj Małecki 2016-12-01 12:21:04 UTC
In short, what happens: I move the mouse at some area in the application and completely nothing happens. In conditions, in which it works correctly, the application should undertake some action based on the fact that the mouse pointer has moved to some other location.

Not sure if this was ever seen or not, however this bug is very hard to reproduce and seems to be somehow bound to hardware of the machine where I can see it.

Hardware data: Dell workstation ("Dell device 04f5", should that be anyhow helpful).

How I know this is a Gtk problem: I tried on this machine various Linux distros: CentOS, Ubuntu and now SuSE. Everywhere it happens, but only on that machine. Also I have this version of Linux installed on multiple other machines and various graphics chipset: evetything is ok on the other machines. I have also replaced the graphics card on that machine (it has builtin Intel chipset, I added extra Nvidia card). Still happens exactly the same way.

Applications where this problem has been seen so far: Google Chrome (and new Opera) and gvim (aka vim-gtk).

What happens in Google Chrome and Opera: The only thing about moving mouse that this application notifies is that the mouse has entered the area of the application window. How it moves inside this area, seems to not be notified at all. Which means that:
 - hovering over links, web elements etc. does completely nothing (should show tooltips, pop up some baloons as defined in the page code etc.)
 - The cursor changes the look depending on what kind of subarea it has entered only at the time when the cursor enters the application. Then it stays the same all the time. For example, if you happened to enter the area where there's a link, it changes the cursor to "clicking palm", but this form of cursor stays all the time, no matter over what you hover, until you exit the area of the application.
 - When the cursor disappears after some time in Youtube video area, there's no way to show it back, and therefore also no way to make the video controls pop up again, any other way than just click the video, which also stops playout

What about other browsers: On Firefox or Konqueror this doesn't happen. The Firefox is actually very interesting because it DOES use gtk - but probably it manages the hovering on the low level by itself.

What happens in gvim: It HAPPENS (not 100% reproducible, it may even depend what kind of text you have loaded to the editor or at which position on the screen the application is in the beginning) that when the cursor once disappeared due to typing a text, never appears again. When it happens, the cursor appears back when you exit the application area, but when you enter back, it remains disappeared.

What about the others: in the experimental vim-qt version it doesn't happen.
Comment 1 Mikołaj Małecki 2017-01-24 14:18:27 UTC
UPDATE:

Opera version 42.0.2393.137 seems to have this problem fixed, but I guess that's just a workaround (which I guess is in case of Firefox as well).

Google Chrome (55.0.2883.87) and Chromium/Linux (55.0.2883.75) still suffer of this problem.

With GVim, the situation is also unchanged.
Comment 2 Mikołaj Małecki 2017-01-26 14:31:59 UTC
Again UPDATE:

Google Chrome version 56.0.2924.76 has this problem fixed, too. After updating Google Chrome, the problem has also disappeared in Chromium.

Problem still remains in GVim.
Comment 3 Daniel Boles 2017-08-30 01:05:23 UTC
How about GVim now?

Which backend, window manager, GTK+ versions, etc?
Comment 4 Mikołaj Małecki 2017-08-30 08:07:12 UTC
With GVim the situation is completely independent on Window Manager. Happens also in a bare X.

I'm using a standard distribution-provided X display. xorg-x11-server package reports version 7.6_1.16.1.

Gtk is 2.24.31, but I don't know whether it matters. For 'gvim' I have "fixed" the problem by self-compiling a version with GTK3 - on GTK3 this problem doesn't happen.

And, I was probably too fast with stating that the problem disappeared in browsers. After some update it reappeared again. Google Chrome and Opera don't use GTK3, so with the browser the problem still persists.

This must be something on the border between X and GTK, looks like some functionality of X that GTK expects to work and it doesn't. For Opera, for example, I'm using such a workaround that I run a VNC server and operate with Opera through a local VNC viewer.
Comment 5 GNOME Infrastructure Team 2018-05-02 17:48:59 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: https://gitlab.gnome.org/GNOME/gtk/issues/713.