GNOME Bugzilla – Bug 521098
The mouse events are being passed on even returning true
Last modified: 2021-07-05 12:36:46 UTC
Please describe the problem: I'm writing an application and i need to be able to lock the mouse buttons events, so the are not passed on, but even using the consume flag the event is being passed on. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 106812 [details] This is the test script i was using I hope this helps
From the registryd's code, if you want to consume the event, you have to register the listener by registerDeviceEventListener or registerKeystrokeListener. The event will not be consumed if you register the listener by registerGlobalEventListener(registerEventListener in pyatspi). I think we need registerDeviceEventListener to consume the mouse event, but I don't find it in pyatspi. I could be wrong, is it a RFE for pyatspi?
Indeed it isn't there, i did a grep in the pyatspi code and there is no registerDeviceEventListener function: grep "registerDeviceEventListener" pyatspi/ -R | grep .py there was no match with the previous command. I'll look how registerGlobalEventListener was created in registyr.py was created and i'll try to create the registerDeviceEventListener... What else should we look for??
You can check at-spi/idl/Accessibility_Registry.idl to see what is missed and useful for pyatspi.
i checked what you suggested and i saw the function there. I thought registerDeviceEventListener didn't exist. I think that we just need to add it to pyatspi...
Just wanted to know if there where some news about this bug?
Created attachment 112077 [details] [review] Proposed patch This patch adds the device event register/deregister methods. I don't think this is going to solve your original problem, since I don't think it is possible to consume device events (besides keyboard events). registerKeystrokeListener takes an EventListenerMode registerDeviceEventListener does not.
Created attachment 112205 [details] Updated test script This test script uses the new registerDeviceEventListener method. It gets the events, but doesn't consume them. I dug through the at-spi registryd code and it seems like it looks for the consumption, but I'm not sure it handles it. Li, do you have any insight?
cspi has the same problem. The api docs for AccessibleDeviceListenerCB () state that it's possible to preempt events by returning True in the callback, but the return value has no effect. This would be very useful to implement sticky mouse buttons.
(In reply to comment #7) > Created an attachment (id=112077) [edit] > Proposed patch > > This patch adds the device event register/deregister methods. > I don't think this is going to solve your original problem, since I don't think > it is possible to consume device events (besides keyboard events). > registerKeystrokeListener takes an EventListenerMode > registerDeviceEventListener does not. > If a DeviceEventListener return TRUE, at-spi-registryd should consume the event.
(In reply to comment #10) > > If a DeviceEventListener return TRUE, at-spi-registryd should consume the > event. > Indeed but the thing is that it doesn't consume the event, I've looked into the code but i can't figure out what's happening I've tried using the event.consume = True or return True and none of them work. Hope this helps cheers
Created attachment 113036 [details] [review] patch to return GDK_FILTER_REMOVE if we want to consume the event If ran two copies of Will's script at the same time, the second one can not receive the events, it is "consumed" by the first script. But the GUI can still receive the events. This means at-spi-registryd will not emit the consumed event to other listeners. I guess this is not enough, we need to consume the event in the hole desktop. I made a patch to return GDK_FILTER_REMOVE if the event is consumed to let GDK remove the event, but seems it doesn't work because the GUI application receive the event almost at the same time (at least before the return of the event listener function in at-spi-registryd), so I don't have a good solution to consume the event in the hole desktop. Is there a function in X can do this? (It is not easy because the GUI listeners will be called before the listener in at-spi-registryd returns)
It may be that the functionality requires XEvIE in order to be able to intercept and consume mouse button events. As such, this problem might be a very difficult one to solve since XEvIE is not reliably deployed on all platforms. Flavio, can you describe the particular use case some more? For example, what is the user interaction model you are working to achieve?
(In reply to comment #13) > It may be that the functionality requires XEvIE in order to be able to > intercept and consume mouse button events. As such, this problem might be a > very difficult one to solve since XEvIE is not reliably deployed on all > platforms. Indeed it seems kind of difficult to implement. > > Flavio, can you describe the particular use case some more? For example, what > is the user interaction model you are working to achieve? > Well, In that moment I was thinking to create a mouse modifier key and so i needed to consume the mouse button[1-5] (depending on the user settings) to execute the application actions.
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/pyatspi2/-/issues/ Thank you for your understanding and your help.