Comment 53 for bug 948788

(In reply to Trevor Saunders (:tbsaunde) from comment #40)

> > > I think the only thing we try to fix here is the infinite recurssion.
> >
> > and code madnness :)
>
> why? the reason for the bug was crashes with a change to atk, so just fixing
> the way we interact with atk should be fine.

the crash was fixed on atk side, we need to make our side robust.

> > > > consumer might need name change event when it asks for the name.
>
> what if there is more than one consumer, then it may be arguably less bad
> for other consumers to get the event late rather than never.

it's intermittent failures, it's not the way the software is supposed to work

> I think the way it works is that consumer processes have a local
> repreentation of atkobject in their process which keeps the name and atk
> updates the name based on name change event. So each consumer can choose
> for itself to use or not use cache as it likes, and might well want to not
> use the cache because it can easily become out of date due to us not always
> firing name change events.

> in any case I'm not really willing to remove the madness we have now atleast
> until we talk to atk people about it, and I don't see a reason to make vd
> block on that.

see comment #7:

"after irc chat with Alejandro it seems we don't need to call atk_object_set_name at all. We override atkobject->get_name so we are guaranteed that we always deliver correct accessible name, in other words it doesn't make sense to call atk_object_set_name to change atkobject->accessible->name."

If you are really sure than some cache exists that we must update then could you please run a testcase with orca or check it with Alejandro?