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 143588 - gnopernicus keynav layer 5- mouse clicks or presses freeze mouse buttons
gnopernicus keynav layer 5- mouse clicks or presses freeze mouse buttons
Status: RESOLVED FIXED
Product: gnopernicus
Classification: Deprecated
Component: srcore
unspecified
Other Linux
: Normal major
: ---
Assigned To: remus draica
remus draica
AP1
: 143957 (view as bug list)
Depends on: 144001
Blocks:
 
 
Reported: 2004-06-02 15:09 UTC by John Crawley
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
srcore stack trace (9.06 KB, patch)
2004-06-08 14:18 UTC, remus draica
none Details | Review
at-spi-registryd stack trace (6.17 KB, patch)
2004-06-08 14:19 UTC, remus draica
none Details | Review
proposed patch for gnopernicus (1.24 KB, patch)
2004-06-10 09:22 UTC, remus draica
none Details | Review
reworked patch (1019 bytes, patch)
2004-06-10 14:43 UTC, remus draica
none Details | Review
proposed patch to temporarily disable Layer 5 (mouse layer) (7.81 KB, patch)
2004-06-18 07:53 UTC, Dana Ormenisan
none Details | Review
a new proposed patch (3.96 KB, patch)
2004-07-02 10:56 UTC, remus draica
committed Details | Review

Description John Crawley 2004-06-02 15:09:49 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.
Comment 1 remus draica 2004-06-04 10:20:51 UTC
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.

Comment 2 remus draica 2004-06-04 11:42:49 UTC
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.
Comment 3 remus draica 2004-06-08 14:18:15 UTC
Created attachment 28467 [details] [review]
srcore stack trace


this bt is made witout XEvIE support
Comment 4 remus draica 2004-06-08 14:19:23 UTC
Created attachment 28468 [details] [review]
at-spi-registryd stack trace


This log is made without XEvIe support
Comment 5 Dana Ormenisan 2004-06-08 15:55:41 UTC
*** Bug 143957 has been marked as a duplicate of this bug. ***
Comment 6 remus draica 2004-06-09 08:19:04 UTC
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.
Comment 7 bill.haneman 2004-06-09 20:04:15 UTC
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.
Comment 8 bill.haneman 2004-06-09 20:05:36 UTC
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.
Comment 9 bill.haneman 2004-06-09 20:14:13 UTC
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.
Comment 10 remus draica 2004-06-10 08:02:40 UTC
Bill, the response to comment #7 is _already_ present in my comment #1.
Comment 11 remus draica 2004-06-10 08:03:59 UTC
I agree with you about comment #8, but desktop is freezed.
Comment 12 remus draica 2004-06-10 08:06:44 UTC
The ideea in #9 sounds great. I will try it.
Comment 13 bill.haneman 2004-06-10 09:11:22 UTC
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.
Comment 14 bill.haneman 2004-06-10 09:13:06 UTC
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.
Comment 15 remus draica 2004-06-10 09:22:48 UTC
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).
Comment 16 bill.haneman 2004-06-10 09:32:17 UTC
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?
Comment 17 remus draica 2004-06-10 09:41:09 UTC
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.
Comment 18 bill.haneman 2004-06-10 10:23:18 UTC
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).
Comment 19 remus draica 2004-06-10 14:43:33 UTC
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.
Comment 20 bill.haneman 2004-06-10 17:00:52 UTC
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.
Comment 21 remus draica 2004-06-11 08:05:42 UTC
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. 
Comment 22 bill.haneman 2004-06-11 11:07:32 UTC
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.
Comment 23 bill.haneman 2004-06-15 15:47:54 UTC
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".
Comment 24 Dana Ormenisan 2004-06-18 07:53:18 UTC
Created attachment 28818 [details] [review]
proposed patch to temporarily disable Layer 5 (mouse layer)
Comment 25 korn 2004-06-25 12:45:32 UTC
DECISION: if XEvIE is present, enable mouse commands.  If XEvIE is NOT present,
disable all mouse commands.
Comment 26 remus draica 2004-07-02 09:14:07 UTC
*** Bug 143957 has been marked as a duplicate of this bug. ***
Comment 27 remus draica 2004-07-02 10:56:43 UTC
Created attachment 29160 [details] [review]
a new proposed patch
Comment 28 remus draica 2004-07-13 12:25:09 UTC
Fixies in CVS.
Comment 29 Patrick Wade 2004-07-28 18:21:38 UTC
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").
Comment 30 Wayne DeAngelo 2004-07-29 14:15:06 UTC
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?
Comment 31 John Crawley 2004-07-29 14:18:54 UTC
The fix appears to work, layer 5 is completely disabled now.