[Bug 948788]

[Alexander Surkov]

(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?

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/948788

Title:
  thunderbird crashed on launch

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/948788/+subscriptions