the problem is that no state-changed events are being received from the
java-access-bridge.  They are being dispatched, but CORBA errors are occurring;
this may be a Java-ORB bug or it may be a java-access-bridge bug, I don't know yet.

the loss of state-change events seems to be related to the clients' use of the
text-change detail info; if clients don't call 

AccessibleTextChangeEvent_getChangeString()

then the CORBA errors don't happen, and the delivery of state-change events (at
approximately the same time) succeeds.  Thus the problem seems not to be in the
state-change events themselves.

more info: the problem isn't specific to getChangeString, a large variety of
client requests can trigger failure, so the problem seems deep in the Java ORB
interoperability or implementation somewhere.  Doesn't look promising.

Note that 'object:state-changed:expanded' events with detail1 "1" (expanded) or
"0" (not expanded) are sent by the Swing demo and java-bridge; you can see these
using at-spi/test/event-listener-test.

Transferred back to gnopernicus/srcore, since the necessary events are being
delivered (despite some warnings from the Java process, which don't seem to be
that relevant to this bug after all).

The problem is that same item doesn't have same value all times. The "pointer"
to object differs from one callback to another or from one call to other.

For example, in this case, more calls of Accessible_getChildAtIndex (tree_item,
i) return different values (in the call tree_item=an item of tree which has
children, i=a valid index in tree_item).

This is not the case in gnome. Bill, is this the right behavior? 

Another observation: the children of an expandable item in the tree are not
shown by at-poke it the item was not expanded before.

Remus, I don't quite understand comment #6.  Are you saying that the
event-source for the expanded events is not the same when you expand and
contract an item?

It's possible and legal for expanding and contracting to cause renumbering of
child indices; gnome doesn't do this, but it's legal.

Yes, the event-source is not same. 

2 calls of Accessible_getChildAtIndex (tree_item, i) return different values
even in a sequence like:

  ......
  fprintf (stderr, "\nFirst call: %xp", Accessible_getChildAtIndex (tree_item ,0);
  fprintf (stderr, "\nSecond call: %xp", Accessible_getChildAtIndex (tree_item,0);

Remus: do the event sources for expand and contract events (i.e. the
object:state-changed:expanded event-sources) change when you expand and contract
THAT SAME object?  

How does that, or the issue in comment #8, prevent gnopernicus from properly
reporting the change?

Remus/All:  When 'expand' events are received, the container is often being
repopulated at exactly that time.  So enumerating children when
state-changed:expanded events are received is a bad idea.

Bill, from what I saw in gnopernicus this is what seems to be happening:

When I move up and down in a tree, gnopernicus recives the events and saves the
event->source of the current object.

When an 'expand' event is recived, gnopernicus checks if that event is recived
for the current object and this check is made by comparring the 2 event->sources
: the one gnopernicus saved and the one recived with the 'expand' event.

For the SwingDemo app, the new event->source is different.
For other GNOME apps it's not. I checked with gconf-editor.

So to answer your question in comment #9 : Yes, the event->sources for the same
object change and gnopernicus is reporting the 'expand' or 'contract' event only
if the event->sources don't change.

Dragan:  I'll make some more investigations of this in the SwingDemo, to see
what might be causing the change.  One expects that the indices in the container
may change as things are expanded and contracted, but not that the actual object
references themselves would change.  If they _do_ change as you say, my
impression is that it would be a Java problem, and might be very difficult to
work around in the bridge.

The workaround for java issue I see here is to check if the item has ACTIVE
state and its parent has FOCUSED state.

Please see <a
href="http://bugzilla.gnome.org/show_bug.cgi?id=169480#c64">comment #64</a> in
<a href="http://bugzilla.gnome.org/show_bug.cgi?id=169480">bug #169480</a>, and
apply similar logic here.  Cache the last focus object, and when you get the
expand/collapse event, if the source isn't the cached atk focus object, walk up
through parents & grandparents comparing to the cached atk focus object.

Created attachment 45475 [details] [review]
proposed patch

Patch tested and committed to CVS head.