GNOME Bugzilla – Bug 125834
Application object fails Accessible_isApplication
Last modified: 2004-12-22 21:47:04 UTC
Consider the mixer applet. This is registered as an application only when a toplevel window is displayed. In an AT e.g. gnopernicus or at-poke, if Accessible_isApplication is called on the the Accessible it returns FALSE. Calling Accessible_isApplication for a normal application e.g. gedit returns TRUE.
Is this a bug? Seems correct to me - i.e. the mixer applet's toplevel isn't really an Application object, is it?
If you say it is not a bug that is fine with me. I was not able to figure out why Accessible_isApplication returns FALSE for this and returns true for normal applications. The other issue is that ATs should not expect to find an Accessible for which Accessible_isApplication returns TRUE when navigating up the object hierarchy. See get_main_widget_from_acc in gnopernicus/srlow/libsrlow.SRObject.c.
On further thought I am much less sure that my initial answer was correct. This is an out-of-process applet, right? Therefore the applet should have a parent that points (eventually) to the gnome-panel, which is an Application object. Is that somehow not the case?
We are discussing an out-of-process applet but the situation is where the applet causes another toplevel window to be displayed. This causes the atk-bridge to register the applet process as an application so that the toplevel window can be seen by ATs.
OK, so the bug is that the Application object which is created when an out-of-process applet posts a toplevel fails Accessible_isApplication?
Yes. That is correct.
Created attachment 21273 [details] [review] Proposed patch
Created attachment 21327 [details] [review] Alternative patch
Created attachment 22054 [details] [review] Revised patch
Revised patch committed to CVS HEAD.