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 756463 - Bogus enter/leave events at screen top/left edge
Bogus enter/leave events at screen top/left edge
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Backend: X11
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-10-12 21:36 UTC by Egmont Koblinger
Modified: 2017-07-02 13:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2015-10-12 21:36:39 UTC
When a Gtk+ window's left or right edge is exactly at the screen's left or right edge, moving the mouse pointer there (using a touchpad) results in plenty of bogus leave and enter events. As you stop moving and release the touchpad, it's totally random whether the last event reported to the app was enter or leave. Settling at the latter might cause unexpected behavior in apps.

Test #1: Launch gtk3-demo -> Event Axes -> Run. Snap the window to the left of the screen. Move the mouse pointer to the left edge, and here move it vertically, try to push it further to the left, or move diagonally to top-left or bottom-left direction. Notice that the "Source: ETPS/2 Elantech Touchpad" and the big cross keeps flashing, and keeps changing color (as it deliberately picks a new color after every leave/enter).

Test #2: Launch gnome-terminal, make it fullscreen. Launch an app that handles mouse, such as mc (midnight commander). Try to click in the topmost pixel row to open mc's menu. Notice that it only works in about half of the cases. (Note: gnome-terminal has a 1px padding, but it's clever to snap clicks in the padding area to the closest cell. The buggy behavior has nothing to do with gnome-terminal's padding per se, the padding can be changed to 0px or a giant value and it's still only the topmost and leftmost pixel row where it misbehaves).

Ubuntu Vivid beta, Gtk+ 3.6.17.

Can reproduce both in Unity (left-hand Launcher autohidden and only revealed when mouse is in top left corner, so we don't conflict with that) and Gnome-Shell.

Cannot reproduce the spurious events with xev.

Cannot reproduce at the right or bottom edges. (My wild guess would be perhaps an underflow of the smooth coordinate causes troubles.)

I'm using the built-in touchpad of a Samsung NP300E5Z laptop. (I see a reasonable chance that the bug might not be reproducible with standard mice. I don't have one to try it out.)
Comment 1 Egmont Koblinger 2015-10-12 21:40:13 UTC
Sorry, too late in the evening...

When a Gtk+ window's left or top* edge is exactly at the screen's left or top* edge, then this bug occurs.
Comment 2 Carlos Garnacho 2015-10-26 16:26:31 UTC
AFAICS this is due to subpixel precision in XI2, when the pointer moves towards the screen edge, we occasionally get a motion event with a very small negative value (moving towards left here), even though we don't get crossing events from the windowing.

This small negative value is enough to make get_pointer_window() checks in gdkwindow.c fail though, GDK will think the pointer is no longer over the window and synthesize a leave, plus maybe an enter when it gets x=0 again in a later motion.

I guess we could check on the gtk+ side whether there's grabs (about the only reason why you might get negative coordinates) and clamp toplevel_x/y to stay within window boundaries otherwise. I'm not too convinced by this check though, would be great to see this fixed on the Xserver side.
Comment 3 Carlos Garnacho 2015-10-26 16:27:13 UTC
FWIW, this can also be seen with xinput test-xi2 when side-maximized.
Comment 4 Carlos Garnacho 2015-10-26 17:29:41 UTC
Filed https://bugs.freedesktop.org/show_bug.cgi?id=92681 about this
Comment 5 Egmont Koblinger 2016-03-06 17:20:32 UTC
Sorry, I misreported the version (two typos), it was Ubuntu Wily* beta, Gtk+ 3.16.7*,

Stil buggy in Xenial beta, Gtk+ 3.18.8.
Comment 6 Henry J. Douglas 2016-10-19 22:46:03 UTC
I see this behavior in Solus (https://www.youtube.com/watch?v=P6OZOfLyxmg&feature=youtu.be). See the video. It also happens in elementary OS at the top panel. Ubuntu MATE 16.10 (which also moved to GTK3) has the same issue on the left and top of the screen. Anything pre-gtk3 works fine, as far as I've seen.
Comment 7 Egmont Koblinger 2016-10-19 23:02:52 UTC
I have a guts feeling that this bug might be the reason for Unity7's launcher sidebar not always revealing when I suddenly move my mouse to the left edge of the screen.

Anyway, I find it unlikely that anything worthful will happen here. X.Org's upstream bug should be pinged, or a better forum found for getting someone fix it.
Comment 8 Carlos Garnacho 2016-10-20 11:28:38 UTC
(In reply to Henry J. Douglas from comment #6)
> I see this behavior in Solus
> (https://www.youtube.com/watch?v=P6OZOfLyxmg&feature=youtu.be). See the
> video. It also happens in elementary OS at the top panel. Ubuntu MATE 16.10
> (which also moved to GTK3) has the same issue on the left and top of the
> screen. Anything pre-gtk3 works fine, as far as I've seen.

gtk+ 2 works fine because XInput2 was not used (it was plain X core events), so pointer events coordinates don't have subpixel precision there.

(In reply to Egmont Koblinger from comment #7)
> I have a guts feeling that this bug might be the reason for Unity7's
> launcher sidebar not always revealing when I suddenly move my mouse to the
> left edge of the screen.

It could be, but AFAIK they don't use gtk+, so it would be really the FDO bug :).

> 
> Anyway, I find it unlikely that anything worthful will happen here. X.Org's
> upstream bug should be pinged, or a better forum found for getting someone
> fix it.

The right forum get it fixed is the FDO bug, working around it in gtk+ is kludgy and not entirely trivial, certainly not a piece of code I'd be comfortable pushing to an stable branch.

I'm actually closing this as NOTGNOME, I should have done so time ago... I encourage you to ping on the FDO bug.