I am very doubtful that this is new behavior.  And strictly speaking,
it's not a bug.  It's an artifact of the way the X server handles
keygrabs; keygrabs produce a focus-out followed by focus-in event.

It may not be feasible to work around this in at-spi or gail, and it
may be that formerly gtk+ detected and worked around this internally,
and that the behavior has changed.  However I suspect that this may
well have been the existing behavior all along.

I very much doubt that the behavior of gtk+ has changed in this area
recently.

I propose that we try a fix something like this:

* we listen for window event as we do currently, but 
  rather than emitting them immediately, we queue them until
  either:

   * a keygrab becomes active, in which case we discard
     the pending deactivate event; OR
   * another event enters the dispatch queue, in which case we
     emit both events; OR
   * the event times out and we emit it.

this will prevent event reordering since we'll always emit deactivate
events if another event comes in before a keygrab becomes active. 
We'll need to similarly ignore window:activate events that come from
the already-active window.

So, the only case in which we'll emit the deactivate event for the
'keygrab' case is the race condition in which a second event is
emitted in between the gtk focus-out event on the window, and the
activation of the X grab.  We can do an immediate check on the X event
queue on receipt of window:deactivate to reduce the likelihood of that
race occurring, which should be nonfatal anyway, it just produces a
little "noise" in terms of very rare emission of spurious "out/in"
pairs for windows.

I don't see a way to eliminate this race totally, offhand; but the
events that might trigger it are likely to be "real" context switches
and therefore associated with valid changes of input focus.

Created attachment 15974 [details] [review]
patch to workaround/fix this problem, eliminates spurious window activation/deact

I attach a patch for this bug; it contains some diagnostic output that
should be 'shut up' before a CVS commit.

The attached patch suppresses window:deactivate/window:activate pairs
that are a result of "focus flashing" from any kind of passive
keygrab/ungrab, unless more than 100 ms elapses between the events. 
It also suppresses object:state-changed:active and
object:state-changed:focussed events that indicate loss of
focus/active status due to the same events.  However it does *not*
suppress the subsequent "object:state-changed:focussed/active" events
that indicate the return of object focus.  I recommend that at-spi
clients detect and ignore "focus' and 'object:state-changed:focussed'
and 'object:state-changed:active' events that are redundant, i.e. they
come from the most-recently-active or focussed object and thus do not
represent a state transition.  There are probably cases which result
in such duplicate focus events anyhow, so at clients should be smart
enough to ignore such redundant information.

Hi Bill
I tested your patch. 
I used last stack from 23 april, and the patch is applied for at-spi
version from 2_05_2003. And this version of at-spi is installed over
the stack.
The listener registration is the following in libke.c (gnopernicus)

retval = SPI_registerAccessibleKeystrokeListener (ke_key_listener,
				      (AccessibleKeySet *) ke_key_keyset,
				      SPI_KEYMASK_UNMODIFIED,
				      (gulong) ( SPI_KEY_PRESSED | SPI_KEY_RELEASED ),

				      SPI_KEYLISTENER_ALL_WINDOWS);

I printed the events which are arriveing from at-spi. This printing is
filtered that print only non "object:" events. Moving in main menu of
gnopernicus the following message are printed. You said that the
window:deactivate event is surpressed. 

AT-SPI Event:window:deactivate
AT-SPI Event:focus:
AT-SPI Event:window:switch
AT-SPI Event:focus:
AT-SPI Event:window:deactivate
AT-SPI Event:focus:
AT-SPI Event:window:switch
AT-SPI Event:focus:
AT-SPI Event:window:deactivate
AT-SPI Event:focus:
AT-SPI Event:window:switch
AT-SPI Event:focus:
AT-SPI Event:window:deactivate
AT-SPI Event:window:switch
AT-SPI Event:focus:

And the window switch event occure some times. To reproduce it you can
move fast between a options. Or move between an options and after all
move wait until gnopernicus finish the speaking. And at the next move
the gnopernicus will say again the "window switch event", and the
printed messages are the same with the above messages.

Other problem what I observed, using the numpad. Now the keyset for
numpad keys is registered with ALL_WINDOWS. When I want to change the
layer some times is the focus is losed. The caret for focus is not
displayed.

bumping up priority as this should be a stopper (blocks, or requires
significant workarounds from, gnopernicus)

I am running gnopernicus from CVS HEAD on Solaris and I do not
understand Paul's comments.

What process is outputting the messages "AT-SPI Event:..."?
Do I need to change gnopernicus to see the problem?

Padraig: 
Yes you need to change gnopernicus to see this output. 
I modified my gnopernicus to test the Bill patch. I modified in 
/kbd_mouse/libke/libke.c st USE_ALL_WINDOWS defined, and I modified 
report_event funtion in SRLow to print the incommind at-spi events. 
This changes are not on CVS, and it has not a patch for this. This 
is only for my test. 
 

When I try to run gnopernicus srcore exits. Do I need to fix that
before I can investigate this bug?

How do you move in main window of gnopernicus? Do you press some keys
on the keyboard?

anymachine:/export/home/padraigo/HEAD/gnopernicus/gnopi 118 %
./gnopernicus
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Atk Accessibilty bridge initialized

**********************
* SCREEN READER CORE *
**********************

Bonobo accessibility support initialized
GTK Accessibility Module initialized
Atk Accessibilty bridge initialized

(srcore:4409): gnopernicus-WARNING **: Exception "Unknown CORBA
exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0'" occured at line
374.

(srcore:4409): gnopernicus-WARNING **: Exception "Unknown CORBA
exception id: 'IDL:omg.org/CORBA/OBJECT_NOT_EXIST:1.0'" occured at
line 429.

(gnopernicus:4396): gnopernicus-WARNING **: srcore exited.

Padraig: 
My word usage was wrong. Navigating in main menu option, not a 
moving in main menu.  
Do you have installed  festival or FreeTTS speech drivers on your 
system? 
 

I have not installed either. Do I need them for this bug?

Probabaly the problem is that the stack cointains a servers for 
these drivers. Please check ? (/opt/gnome-2.2/lib/bonobo/servers). 
Leave only the GNOME_Speech_Synthesiser_...ViaVoice.server. Delete 
all speech servers which are not installed on your system. 

Hmm, if you have no working speech drivers, and this causes
gnopernicus to die, then there's a gnopernicus bug IMO.

Padraig definitely doesn't have ViaVoice.  Probably he has no TTS at all.

Correction: I am using Clifton's GNOME 2.2 build for Solaris which 
has a FreeTTS speech driver.

Created attachment 16493 [details] [review]
Updated at-spi patch

Paul,

Please try the updated at-spi patch. If this does not give you the
results you require please send me the changes you made to gnopernicus
for testing.

Padraig: I will test the patch. 

fix is in registryd, so changing component to "registry".

padraig, this version of the patch seems not to be correct.  It is
consuming window:activate events that occur due to metacity keyboard
navigation (at least on my system).

To test: Alt-TAB (releasing in between TAB presses, to make sure that
the activate signal is emitted).  You will see (if you either turn on
SPI_EVENT_DEBUG or run a client that listens for window events) that
the activate events don't generally get emitted, though the deactivate
events (oddly) do.

please let me know if you see this; maybe it's just my system that's
broken for some reason!

Hi: 
It seem to be not correct results. I tasted it whit gnopernicus and 
I noticed for example when I navigated between an options the 
windows switching event occure. I will attach the patch for 
gnopernicus, whit I tested the new at-spi patch, if you has speech, 
you will hear that the "windows switch" events.  

Created attachment 16623 [details] [review]
Modification for gnopernicus to test a new at-spi.

Bill,

I do not see the problem you describe. Does your use of the word
generally mean that it sometimes works correctly?

Paul,

I have applied your gnopernicus patch. I am seing the following
message being output by at-spi-registryd:

*** Message: Could not complete key grab: grab already in use.

I need to determine what is causing this.

Padraig: the message "grab already in use" means that paul is
registering for some keyevent combination which we can't honor. 
Probably either an ALLKEYS, or for a modifier/key combination that's
already bound by some other grab client such as metacity.

We cannot support ALL_WINDOWS listeners for such key combinations;
clients must detect this condition and use a different key combination.

Padraig: I take it you are referring to an email from me about the
window events?  I can reproduce the problem 100% 
of the time on my system; I never (with your patch) get
deactivate/activate pairs when switching windows with Alt-TAB.

Paul,

What do you use to navigate between the options? Is it the arrow keys?

Padraig: 
Yes, I use a arrow keys to navigate. 

Paul,

I do not see the problem you have reported. Can you send me the outpit
from gnopernicus. Also please run at-spi-registryd in a terminal so
you can get its putput also.

The message grab already in use comes from attempting to grab a
keycode of 0. This happens on Solaris because XK_Alt_R and
XK_Control_R do not have keycodes. I will update
deviceeventcontroller.c to not atttmpt to grab a keycode with value of
0.

Bill,

I cannot reproduce the problem you describe. Can run at-spi-registryd
in a terminal window so I can see what output it is generating.

hi padraig: could you log an Xserver bug about this?  All keys should
have (non-zero) keycodes.

Created attachment 16949 [details]
log generated by at-spi-registryd when using mouse to navigate windows

Created attachment 16950 [details]
log generated by at-spi-registry when doing same window activation via keyboard

about the previous attachments:

(1) your patch was applied, but I removed one of the two "push" and
"pop" fprintfs in each case

(2) nav was between three windows:
(a) - gedit
(b) - gnome-terminal
(c) - xterm (where at-spi-registryd was invoked - inaccessible)

Navigation sequence was (starting state: xterm focussed)

a, b, a, c.

Expected window:events would then be

window:activate [gedit]
window:deactivate [gedit]
window:activate [gnome-terminal]
window:deactivate [gnome-terminal]
window:activate [gedit]
window:deactivate [gedit]
(no activate for xterm since it's inaccessible)

- Bill

Created attachment 16953 [details] [review]
new patch, same as previous but with new window-listener-test.c prog.

Created attachment 16954 [details]
output of window-listener-test showing interleaved "activate" events during keynav.

Hi Padraig:

We may have a metacity problem here, or perhaps gail.. hard to say.
I attach a new patch which includes a new window-listener-test.c and
Makefile.am entry.  This new program shows a problem, visible in the
output log I attached after the patch (above)

When doing keynav, the activate/deactivate pairs from window _from
which we are navigating_ seem to get deferred, and then delivered
after the Alt key is released.  Unfortunately this means that they get
delivered AFTER we've gotten the (current, correct) activate event
from the newly-focussed window, thus:

window:deactivate "old window" [window that was focussed before Alt-]
window:activate "new window" [window focussed by keynav action]
window:activate "old window" [deferred event is sent when Alt is released]
window:deactivate "old window" [and deferred "retraction" of above event]

Ending state, then, appears to the AT that no window is focussed at all.

Created attachment 16955 [details]
window-listener-test.c source

Bill,

I see what you mean now.

gail could be changed to emit the activate signal on a timer in case
there is a deactivate signal about to come in which case neither
signal is emitted.

I would also have to check what happens with Java applications.

I'm sure you'll agree that avoiding the timer would be better, if
possible - fewer race conditions and latencies.

I'd like to figure out why the events are coming in this order first -
perhaps we can fix the root cause, which would be preferred.

We can do much about the order in which the events arrive at the
registry daemon as they are coming from different processes. 

However the registry daemon could handle them:

if event is activate and previous activate/deactivate was activate
  cache the event
if event is deactivate
   if have cached activate
      if cached activate and deactivate match 
         discard events
      else
         emit deactivate
         emit cached activate

I have logged bug 114037 against metacity for the extra focus-in and
focus-out of old focus window when Alt+Tab is used to mode focus.

Created attachment 17442 [details] [review]
at-spi patch as applied.

we discussed this an saw that the current issue is that if the
activate/deactivate pair brackets a context switch such as a focus
event, the events are sent on to the client.

workaround is for the client not to register for ALL_WINDOWS key
notification for 'informational' notifications that cause context
switches, for instance the arrow keys.

I have also put in a minor change to the patch so that focus: events
can be deferred until either a timeout or the receipt of a
window:activate event, this should solve the issue with arrow keys.

Downgrading priority on that basis.

A suggested more general fix, which I think would indeed be a good idea:
* don't emit window:activate/deactivate events from the gtk+ window
  signals anymore, 
* instead listen to the _WM_ACTIVE property which
  metacity sets on the root window; this is what the window switcher
  applet does now in libwnck.
* then we need to use the XWID window ID to associate the _WM_ACTIVE
  notification with a toplevel GtkWindow's accessible.

I think this code would probably need to live in the bridge(s), but
it's conceivable that it could be in registry.c instead.  Putting it
in registry could be a problem for Java apps - likewise Java apps
probably would need to retain the current implementation rather than
listening to _WM properties in the JavaBridge.

The end result of this fix would be that the active window would
always match the on-screen visuals since metacity, libwnck, and at-spi
would be using the same logic/information source for the
window:activate/deactivate state.

lowering severity based on recent tweak since we no longer get fooled
by interleaved focus: events.

Created attachment 17986 [details] [review]
Proposed patch for gail

The proposed patch attempts to emit window:deactivate and
window:activate events when _NET_ACTIVE_WINDOW property is changed.

A problem with this patch is  that there is no guarantee that the
registry will receive the deactivate event before the activate event
when switching from window to window.

A problem with the proposed patch is that notification of focus for
objects within the window mwill occur before the notification of the
active window.

I tested the at-spi with the patch for gail. The
window:activate/deactivate events are comming.

Paul,

What exactly is the test case where you see activate/deactivate
events?

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

Hi Padraig.
I made a new test with a new stack from 05.08.2003 and whit at-spi
from 10.08.2003 (from CVS Head).
The patch will send. This patch need to applied for event-listener-test.c
The patch will put the code part from keypad-test.c to have a 1 output
for events.

The window activate events are still.
Steps to reproduce:
1. Run gtk-demo/button-boxes
2. run event-listener-test
3. Press NumLock to be active
4. Press Numpads keys
5. Press for more time whitout to release the key e.g. numpad_1 for
few seconds. (4-5 seconds)

I opbtained the following output:
"
keypad KeyEvent ± [keysym 0xffb1] (keycode 87); string=1; time=f54e8f91
(detail) window:deactivate Button Boxes 0 0
context string Button Boxes
object:state-changed:focused Help
object:state-changed:active Button Boxes
(detail) window:activate Button Boxes 0 0
context string Button Boxes
object:state-changed:focused Help
object:state-changed:active Button Boxes

keypad KeyEvent ± [keysym 0xffb1] (keycode 87); string=1; time=f54e8fb3
(detail) window:deactivate Button Boxes 0 0
context string Button Boxes
object:state-changed:focused Help
object:state-changed:active Button Boxes
(detail) window:activate Button Boxes 0 0
context string Button Boxes
object:state-changed:focused Help
"
You can see that the window:active

Created attachment 19144 [details] [review]
Test patch for event-listener-test.c

Paul,

What window has focus when key in number pad is pressed?

Padraig

From gtk-demo the button boxes window had a focus.

Here is the output I see when I press NumLock followed by numpad_1
twice. I do not see the window switch events you see. Are you using
at-spi from CVS HEAD? 

(detail) keyboard:modifiers main 0 16416

keypad KeyEvent Þ [keysym 0xffde] (keycode 93); string=; time=fbcef03e
object:state-changed:focused OK
object:state-changed:active Button Boxes

keypad KeyEvent Þ [keysym 0xffde] (keycode 93); string=; time=fbcf3ebd
object:state-changed:focused OK
object:state-changed:active Button Boxes

When I ran gtk-demo in a debugger and put a breakpoint in
atk_object_notify_state_change I saw a deactivate event. I will
investigate further.

Does increasing the value of exit notify timneout help. See line 875
of at-spi/registryd/registry.c?

  registry->exit_notify_timeout = 100;

Padraig:   
I need some explanation. "Window switch" event are generated by   
gnopernicus from at-spi "window:activate" event. This event will 
show that the window is losed the focus.   
The title of this bug is not a good. I will change it to "Unwanted  
'window:activate' events occur when use  
SPI_KEYLISTENER_ALL_WINDOWS for catch a keyevents."  

If a window:activate event for a window occurs within 100 milliseconds
of a window:deactivate event the code in at-spi in registry.c discards 
both the events and does not report them. That is why I asked you to
try increasing the value of 100, to say, 400.

For gnopernicus need to not came the window:activate and focus 
events in case when the numpad keys is pressed. These event could do 
gnopernicus tor eport a wrong event or wrong object. 
We tested to changed your proposal, I noticed that if you still 
press the numpad keys the activate events are comming. Other 
observation if not still press the key an activate event aren't 
comming but the focus event does. 

Paul,

In your comment on August 12, I do not understand step 5. When I press
a key and do not release it for a few seconds I see many KeyPress
events reported.

Yesm you have right, and this is what I wanted, because if I hold 
press the key, the appearance of window:activate and focus event is 
greater. If I hold press the event evry time the window activate and 
focus events came.

Paul,

I do not understand why you see the window:activate events and I do
not. Are you using at-spi from CVS HEAD?

Padraig

I use the at-spi from CVS HEAD.

Please recompile registry.c with SPI_QUEUE_DEBUG defined; see line 28
of registry.c.

Run at-spi-registryd in a terminal by killing at-spi-registryd process
and running

/opt/gnome-2.4/lib/at-spi-registryd
--oaf-activate-iid=OAFIID:Accessibility_Registry:1.0 --oaf-ior-fd=33

Please send me at-spi-registryd output when you get window:activate
events when pressing keys in numpad.

Padraig
I have some problem with your description.

I checked out the at-spi from CVS Head. I modified the state of flag
in registry.c I compiled it and I installed in /opt/gnome-2.4.

The specified path( /opt/gnome-2.4/lib) where are the
at-spi-regsitryd, has a at-spi-registryd but it is old. The new
at-spi-registryd  is installed in /opt/gnome-2.4/libexec. I copied
this version in /opt/gnome-2.4/lib.
I put in registry-main the debug message for look if it can to restart
the at-spi-registryd.
I tried to stop the actual at-spi-registryd but I could not do it. I
tried to restart simple whit a command but I looked that the
at-spi-registry still running. What happenening? What I made wrong?

I restarted my systems, but no output show by at-spi. I tried to run
event-listener-test test application but it crashed my sysmtem. 
Can you help me where I made fault?

We need info on this bug in order to proceed further, since we cannot
reproduce it and need your feedback.

Paul, if accessibility is "on" on the desktop, you will find it hard
to kill at-spi-registryd and restart a new one.  Try using xterm, and
typing

ps -elf | grep at-spi-registryd

then for instance if you see at-spi-registryd is process 25433,

type

kill -9 25433; /opt/gnome-2.4/libexec/at-spi-registryd


that way the kill and the restart happen on the same line and,
usually, close enough together in time that a new at-spi-registryd
doesn't get started by some other client first!  Also please pass the
parameters Padraig requested to the at-spi-registryd command above
when you try it.  I hope this helps

- Bill

Bill: 
Thanks for help. I could to stop and restart the at-spi-registryd. I 
used the konsole which is not accessible.  

I have worked with Paul on this and what I see is that most of the
time the window:deactivate, window:activate events arrive in the
at-spi-registryd withinn about .025 seconds. In that case the
window:deactivate and window:activate events are discarded. However, a
lot of events are generated the time difference between the arrival of
the window:deactivate and window:activate events are greater. I have
seen differences of about .5 seconds.

It seems that no matter what value is set for the timeout value for
the registry to wait for a window:activate event after receiving a
window:deactivate event there will always be a chance that the
activate event will not arrive in time.

Is this something we can live with?

If this problem only happens under "high stress", i.e. when a key is
pressed and held for a long time, then in my opinion it is a bug we
can tolerate.  I don't see a good alternative, if we cannot get the
WM_ACTIVE solution to work (due to the fact that WM_ACTIVE messages
may not be sent until after 'focus:' events).

One alternative would be to revive the WM_ACTIVE fix, and in add some
logic which also emits activate/deactivate events in conjunction with
'focus:' if they haven't already been sent, i.e.

* if a focus event is about to be sent, 

* check to see if the widget's toplevel state is active (probably
would need to be a private bitflag of some kind stored in the
GailWidget, for efficiency reasons)

* if the toplevel isn't already active, emit window:activate for it
and set ACTIVE state before emitting the "focus:" event.

That's certainly extra work but it might be possible to produce a
reliable fix that way.  Opinion?

(BTW I don't suggest doing the above new logic for 2.4.0, but we could
try it for 2.4.1).

Paul, I think that the Solaris/number-pad issues with non-ALL_WINDOWS
keylisteners are serious enough that we should change the listeners to
ALL_WINDOWS even if this bug is still occasionally noticeable - at
least, if the bug can be made less common by not using key-repeat.

thanks

Bill

Bill, 
The problem not happen only when is under stress. If it use 
ALL_WINDOW flags and the callback function return a TRUE (to eat the 
key), the side effect is arraving. I don't think it is good to use 
ALL_WINDOW flag now. We need to work on this. 

Paul: I think I understand what you mean about "press and hold" the
key.  The key grab from X isn't released until the key-release event
happens, I think, which means that (I think) for consumed ALL_WINDOWS
events, at-spi won't get the focus-in event on the toplevel window
until you release the key.  In most cases this will be too late to
avoid emitting the window:deactivate event from the timer.

Padraig, does this shed some light on the issue?

Created attachment 19587 [details] [review]
Proposed at-spi-registryd patch

Paul,

Can you check that the propsoed patch suppresses the unwanted focus
event when window:deactivate and window:activate events are discarded.

Bill,

Can you check the patch for suitability for committal.

Hi Padraig
The patch is working. The focus events are not comming. Thank you.

I have a little observation about this keyboard grabbing.
The user if press the numpad keys  under stress or to fast the
activate event are comming sometimes, and the focus is losed
sometimes. I think for this version it is acceptable. It need to fix
these problems too in the future to have a good product.

Other observation:
I don't when it is changed, but I observed the followings.
When we want to made a dnd when the mouse left is still pressed the
numpad events are not cameing. How to reproduce this and more detail I
will send in the mail.

Padraig:

Patch looks good (if a bit fragile; it depends on our getting
state-changed:focus==false events from the currently-focussed widget
in the deactivated window prior to the 'focus:' event's receipt).  

I think we should request permission to apply.

Patch to at-spi-registryd applied to CVS HEAD.

I don't think that this bug had to close, because the patches in
at-spi it solve partially the bug, under stress the bug still yet. It
seems that the gnopernicus users are using the gnopernicus
screen-review and any other command feature under stress, and report
to us that they lose the focus (for e.g. in screen review mode) when
it navigate in windows, and  use a command (numpads). 
I rememberd that Bill said that the correct solving are not in at-spi,
it is in gail and gtk  libreries. Have I right?
I want to leave open this bug until this issue is not fixed totally.

I would much prefer if a new bug was opened for this problem rather
than reopening a very long bug.

yes.  This bug is closed unless a proven regression from the existing,
admittedly imperfect, fix is demonstrated.

Given that we have a fix when XEvIE is available and as good a
workaround as can be achieved when XEvIE is not available, the bug is
fixed and will remain closed.

Paul: 

To respond to your question, Padraig and I did not find the alternate
solution involving gail and the WM_ACTIVE state workable; in other
words that solution does not appear to be feasible.  We believe that
the current workaround is the best that is achievable with GNOME/gtk+
and X, without an additional X server extension like XEvIE.  Therefore
those aspects of this bug are "NOTGNOME".  We could open a new bug
which only refers to the fact that focus events occur intermittently
under stress, but I do not think it would serve a purpose as that bug
would be unfixable without XEvIE.  Since we have now integrated XEvIE
support (where available) into at-spi, I think we have a complete fix
under those conditions.

If somehow this fix or behavior regresses, that is gets noticeably and
consistently worse due to changes in GNOME, then we should reopen this
bug so that we can fix our workaround.  But I believe that any
remaining problems with our workaround are outside of GNOME's control.

Reopening because of bug #163755.

*** Bug 163755 has been marked as a duplicate of this bug. ***

I don't think we should reopen this old bug, see comment #84.