Bug 71762 - button passive grabs don't trigger the right XI2 crossing event mode
Summary: button passive grabs don't trigger the right XI2 crossing event mode
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/Core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-18 22:56 UTC by Carlos Garnacho Parro
Modified: 2018-12-17 17:26 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Carlos Garnacho Parro 2013-11-18 22:56:52 UTC
If a client (normally a reparenting WM) sets a passive button grab and it is triggered when the pointer is above another client's window (eg. a WM-managed window), crossing events will be rightfully generated, however XI2 crossing events in the second client don't contain the expected mode, XINotifyPassiveGrab/Ungrab would be appropriate here, but XINotifyGrab/Ungrab are used instead.
Comment 1 Carlos Garnacho Parro 2013-11-25 17:22:41 UTC
2 Patches are now on xorg-devel,
http://lists.x.org/archives/xorg-devel/2013-November/039220.html
Comment 2 Chris Townsend 2013-11-26 16:49:53 UTC
Hi Carlos,

I tried these patches.  Coupled with the Gtk+ fix, this does indeed fix the various scrolling issues!  Hopefully the patches will be reviewed/accepted soon.

Thanks a million for addressing this!
Comment 3 Peter Hutterer 2013-12-03 00:53:09 UTC
Do you have a test case for this? I knocked up a simple one with two XI2 clients, one creating a window with enter/leave on a window, one with enter/leave on the button grab on the root window. Neither client gets an event and a printf in the server shows nothing is written onto the wire either (only the button event to activate the grab).

If I change to an active grab + ungrab, I get the events correctly.
Comment 4 Chris Townsend 2013-12-20 15:03:26 UTC
Is there an ETA on when the patches are going to be merged into master?
Comment 5 Peter Hutterer 2013-12-22 22:47:17 UTC
Please see the follow-up post here:
http://lists.x.org/archives/xorg-devel/2013-December/039346.html
Comment 6 Chris Townsend 2014-02-03 13:51:52 UTC
Since the proposed patches to X have been rejected, what can be done here to fix this properly?
Comment 7 rockorequin 2014-02-05 23:56:09 UTC
IMHO, this is quite an annoying regression. 

Just in case it's not obvious what the effect is, there are steps to reproduce it at https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1240957: you just have to run two apps like gnome-terminal and nautilus and try using the mouse wheel to scroll them. nautilus no longer scrolls with the mouse wheel unless it has focus, whereas gnome-terminal always scrolls. Scrolling without requiring focus has always been one of the nice things about X desktops, and now it's inconsistent and broken.
Comment 8 GitLab Migration User 2018-12-17 17:26:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org'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.freedesktop.org/xorg/xserver/issues/566.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.