GNOME Bugzilla – Bug 144001
every key press event reported twice when using XEvIE
Last modified: 2004-12-22 21:47:04 UTC
Every key press event is reported twice when at-spi is compiled with XEvIE support. IMPORTANT: key release event is reported only once.
I change the priority to blocker because this bug makes gnopernicus layers unusable.
Created attachment 28494 [details] [review] a stand alone tester to prove this behaviour If this issue is not present, try to run 2 instances of the tester.
Remus: can you explain your last comment: "If this issue is not present, try to run 2 instances of the tester." ? Thanks.
"Blocker" is too high a priority for this bug, but possibly "High" is not high enough. From previous code inspection I am surprised at this bug report, as the XGrab code path should not be exercised if Xevie is present.
Once seemed to me that the bug is not present. After starting a new tester, it was present. Probably I didn' restart the computer. This bug is always present on my computer.
If this affects all recent Solaris versions, it might be AP0.
Remus, Can you give me an exact test case for reprodicng this bug using your tester program? I am having difficulty reproducing it on Solaris.
My problem was that I had mouse keys enabled when I was trying to reproduce this. I now have my number pad working correctly. I do not see this bug on Solaris.
Although I was not able to see two events when using Remus's test program I am seeing strange behavior in gnopernicus when at-spi-registrysd is built with XEVIE support. It seems that use of the number pad for layer keys is not working. I will investigate further.
Remus, can you provide info about exactly what build you are running? Padraig cannot reproduce the problem with your test program (though he has uncovered another xevie issue). It's not obvious that the issue Padraig has found is related to your report, so we still need more info. Thanks.
This bug is reproductible on my computer under Suse 9.0.
Now that I have a version of XEVIE that works on Solaris I think I am seeing this bug. When I ran the test program and pressed 0 key on the number pad once I got the output below. Remus, Is this was you are seeing? GTK Accessibility Module initialized Command key registry: result succeeded L0 KeyEvent ° (keycode 102); string=0; time=4e423b60(4e423b60) L1 KeyEvent ° (keycode 102); string=0; time=4e423b90(30)
When Xevie is used to intercept keystrokes the Xevie client will receive KeyPress and KeyRelease events on the keys the Xevie client chooses to consume. This means that at-spi-registryd receives a second KeyPress event for a key which is consumed.
Created attachment 30440 [details] [review] Propsoed patch
this doesn't make sense: if the client has consumed the event, it shouldn't see another instance of it. IOW, failing to call XevieSendEvent should result in NO key press and release event in the client. Am I missing something here?
I re-read the patch. Xevie should definitely NOT be behaving this way, it makes no sense.
BTW, is this patch even 100% safe? Are we assured that the keypress/release events in question will always be the NEXT event received?
Padraig, at comment #12 is same output as on my computer.
Remus, What is the behavior if you apply my proposed patch? Bill, The comments in #13 are from an email I received from Derek Wang. Once we establish whether the behavior the patch is expecting is what should be happening we can make the patch safe, if that is necessary.
If an Xevie client "consumes" an event, that event should not be propagated further, even to the client. Getting two notifications of 'consumed' Xevie events seriously compromises the usefulness of the API (since a client must, in this case, implement some sort of rejection/matching logic for duplicate events). SUch matching logic is subject to failure in race conditions unless a queue of events is maintained which is searched on receipt of EVERY relevant X event.
Hi, I tested Padraig's patch and it works ok for me. The pressed key is no longer reported twice.
Padraig's patch will work MOST of the time, but the xevie client shouldn't have to use the patch, it's a workaround for redundant notifications that should not be occurring.
The problem was finally tracked down to an XEvie bug, when XKB is present. Closing as NOTGNOME.