GNOME Bugzilla – Bug 143588
gnopernicus keynav layer 5- mouse clicks or presses freeze mouse buttons
Last modified: 2004-12-22 21:47:04 UTC
Using Gnome built with gnopernicus 0.9.4 on 28th May 04 -Launch gnopernicus with speech enabled -Make sure num-lock is on and press 0 followed by 5 on the num-pad -Press either 1,2,4,5,7,8. Notice that the associated actions of these keys do not occur. Also, the actual mouse buttons stop working and Alt-Tab doesnt work. The mouse cursor still moves though.
User can generate a mouse event by calling SPI_generateMouseEvent. Calling the function in a simple test program will generate always the action. In gnopernicus, when this function is called (by pressing a key from numpad) the system freezes. The call of SPI_generateMouseEvent returns _always_ a TRUE value. I have tried another scenario, to call that function on a timer. In this case, on my computer if the fuction is called in a short period of time (100 ms) the resut is the same. If the function is called after 3s=3000ms gnopernicus behaves as user expects.
If mouse functions are maped on a user combination key, this bug is not present. If the keypad listener is registered with SPI_KEYLISTENER_NOSYNC|SPI_KEYLISTENER_CANCONSUME instead of SPI_KEYLISTENER_ALL_WINDOWS this bug is not presnet also. In case of SPI_KEYLISTENER_ALL_WINDOWS flag, focus is gone from UI for a short period of time and will appear again on _same_ object. I belive that bug this bug has a connection with bug 108664 and bug 134003.
Created attachment 28467 [details] [review] srcore stack trace this bt is made witout XEvIE support
Created attachment 28468 [details] [review] at-spi-registryd stack trace This log is made without XEvIe support
*** Bug 143957 has been marked as a duplicate of this bug. ***
This bug is _NOT_ present is XEvIE is installed on system _AND_ at-spi was recompiled and _reinstalled_. Also, some changes are needed in gnopernicus to check this because of bug 144001.
The possible relation to bug 108644 _could_ happen due to the use of XTest to synthesize an event between the grab/ungrab from the command key. Remus, what happens if you generate the mouse event in an idle handler instead of inside the callback? If this fixes the problem, then the above could be the reason. However if generating the mouse event in an idle handler doesn't reliably fix the problem, it is unlikely to be related to 108644 in my opinion.
The stack traces tell us that gnopernicus and at-spi-registryd are both "running normally" after the behavior is seen. There's nothing in the stack traces that suggests a problem.
Remus: I have a clue about why the timer results were as you saw them... I think you may need to wait until after the command key is released. This is a problem since it's difficult for us to provide good key-released events without XEvie, but there ought to be a way to wait to generate the mouse event until after the key has been released. This should avoid some possible side-effects between the X key grab and the mouse event, if we can do it.
Bill, the response to comment #7 is _already_ present in my comment #1.
I agree with you about comment #8, but desktop is freezed.
The ideea in #9 sounds great. I will try it.
In comment #9, I am thinking that the timer results you saw (comment #1) had to do with whether the key had been released (and with it, the XGrab) when the button event occurs or not. Note that an X key grab isn't released until the key itself is released, so the X keyboard is grabbed while the mouse event is synthesized (if the synthesis takes place inside the callback). If your idle handler takes care not to execute while in a key-command callback, then just executing the mouse synthesis inside the idle handler may be OK. Note that in that case, we must be careful that our tests for "in-callback", or whatever test is used, is really accurate - that is, we need to think about the fact that the CORBA reply from the callback to at-spi-registryd needs to have completed before the generate-mouse-event command is called.
By the way - there's still a fair bit of conjecture in my comments above. Perhaps Padraig will have some thoughts about how we can best debug the issue inside at-spi-registryd, if the problem is introduced by calling generateMouseEvent while a listener return is still pending.
Created attachment 28540 [details] [review] proposed patch for gnopernicus This patch will generate a keyboard event for gnopernicus when key is released instead when it is pressed. This works on my computer (with and without XEvIE).
Remus: would your patch change the behavior to "execute command on key release" for _all_ command keys? I don't think we should make such a change without discussion, it's not obvious that it's what the user wants/expects. Could we make this change only for commands that generate/synthesize mouse or keyboard events?
Yes, the patch will change the behaviour for all mapped commands. No, is not possible to see if that key (or key combination) will generate a mouse event. But I can limit the change to numpad.
Remus: I think limiting the change to numpad isn't sufficient. However, if the mouse-and-key-generating commands have a separate listener (i.e. separate from the listener for other command keys), the change in behavior can be limited to those commands (where it is necessary).
Created attachment 28561 [details] [review] reworked patch This patch will apply the cahng only for keys (or key combination) which may generate a mouse event.
Hi Remus: The new patch has the same problems as the old one, except that key echo isn't affected. But it still changes _all_ gnopernicus commands to work on key-release instead of key press, which isn't OK in my opinion. Gnopernicus needs a different listener for the mouse layer, or else we need to use user_data to determine whether the listener is registered for a mouse-or-key-event-generating key or a "normal" command key.
I don't agree the ideea to make a diference between a key (or key combination) which generates a mouse command and the others. This is very hard to be implemented. "mouse layer" is only a perception for user because in code is no such concept. And I don't agree it. When user press a key to execute a commnad, he, ussually, doesn't hold it pressed. So, in my oppinion will be no difference (or almost none) for him.
We need to discuss this in our weekly meeting. I think users expect commands to take effect on press, not release, in most cases. I also don't see why implementing my suggestion would be difficult.
It was suggested in our weekly meeting that it would be better to turn off the mouse control features if Xevie is not available, than to change gnopernicus' layer commands to "on-release" instead of "on-press".
Created attachment 28818 [details] [review] proposed patch to temporarily disable Layer 5 (mouse layer)
DECISION: if XEvIE is present, enable mouse commands. If XEvIE is NOT present, disable all mouse commands.
Created attachment 29160 [details] [review] a new proposed patch
Fixies in CVS.
PW->JC John, can you verify this fix please? I haven't reproduced the 'side' issues you mentioned ("the actual mouse buttons stop working and Alt-Tab doesnt work").
Update, please let me know if the patch fixes the reported problem and if so what nightly tarball with garnome will it be dropped into?
The fix appears to work, layer 5 is completely disabled now.