This may be a two-parter (or more than that, but I'm only aware of two significant issues).

Part 1: You can get trapped in the notification area (whether you're using Orca or not).

Part 2: Something happened to the applets in Feisty (GNOME 2.17 in general??).

Re part 2:  I've been doing some digging, but I suspect it's not directly a bug in gnome-panel, but rather a side effect of something else.  Here's what I (think I) know so far:

In Edgy, navigating to an embedded component causes Orca to speak the name of the embedded component if present (e.g. "GNOME Weather") or its description (e.g. "x items in trash").  In Feisty, this no longer occurs.  

I tried at-poking the top and bottom panels in Feisty and did not see any information regarding the embedded components -- only the panel that contained them.  It turns out you need to install libgail-gnome-common (and perhaps libgail-gnome-dev) to have access to that.  HOWEVER, that only causes them to show up in at-poke; they're still not spoken.  

Further digging reveals that all of the non-standard applets no longer give us an object:state-changed:focused event -- as they do in Edgy.  We should be able to script around this if push comes to shove because we still get an object:state-changed:focused for the item that gave up focus and, with libgail-gnome-common/dev installed, we can obtain the details of the embedded component that gained focus.  As an aside, perhaps we want to have a special gnome-panel.py anyway to provide more compelling access (e.g. we could be speaking the location, temperature, and current conditions instead of merely "GNOME weather").  Regardless....

In an attempt to figure out where things broke, I started with a fresh (fully-upgraded) install of Edgy and then installed the Feisty versions of gnome-panel and gnome-applets (along with all of their dependencies, of course).  Orca still speaks those items as expected which is why I don't think the bug lies there.  I've subsequently upgraded various and sundry packages and libraries that seemed relevant, and there still was not a problem.  When I attempted to upgrade to the latest at-spi (without doing a full dist-upgrade), a number of things broke.  So there is apparently a functional dependency that is not an official dependency -- and without knowing what that is, I cannot continue in my "let's see what broke gnome-panel" quest.

Phew!  My plan was to dig a bit further, but since this was entered, I figured I'd comment. :-) 

Follow-up:   I just at-poked at this again (there have been quite a few Feisty updates the past couple of days).  It seems we now *are* getting the object:state-changed:focused event for the embedded component that gained focus -- but it's the panel that is claiming focus rather than the embedded component.

I bet it wouldn't take too much to create a compelling gnome-panel.py that provided compelling access (without "scripting around" bugs).... What do y'all think?

More follow-up:  Since I cannot seem to go progressively forward (updating slowly but surely from 2.16.x to 2.17.x) I gave backwards a shot. :-)

*Something* that changed in at-spi between revisions 858 and 868 seems to be responsible for two significant problems w.r.t the accessibility of the applets in gnome-panel:

1. The aforementioned lack of object:state-changed:focused events for the majority of the applets.* 

2. Nearly a complete lack of events for the context menus associated with those applets (which renders them inaccessible as well).

Using rev 858 on Feisty, access to the applets and context menus is the same as on Edgy.

I'll try to narrow down the exact change.  Stay tuned!

* Note:  It turns out that in Feisty, we don't get the needed events for the embedded component -- even for the panel -- without "tickling"/poking the hierarchy.

Methinks it's the patch to bug #163132.  Having applied that patch to revision 858, I see problems #1 and #2 from my previous comment along with another problem which I didn't notice earlier:  

3. A lack of events when an applet displays tooltips (either when you hover the mouse pointer over an applet or move focus to the applet and then press Control F1).

Pre-patch, we get those events....

I guess the question now is:  Does the patch expose a bug in gnome-panel, or is the patch itself the problem?

Add cc to gnome-a11y-bugs-ext@sun.com

OK, the following patch to bridge.c was incorrect:

   else
     {
-      spi_atk_bridge_do_registration ();
+      success = spi_atk_bridge_do_registration ();
+    }
+  if (success) 
+    {
+      spi_atk_register_event_listeners ();
+      spi_atk_bridge_init_event_type_consts ();
+    }
+  else
+    {
+      atk_bridge_initialized = FALSE;
     }
-  spi_atk_register_event_listeners ();
-  spi_atk_bridge_init_event_type_consts ();
- 
 
The spi_atk_register_event_listeners() and
spi_atk_bridge_init_event_type_consts() calls should NOT have been moved into a conditional, since embedded widgets (i.e. things that don't register as fullblown applications until they pop up a toplevel window) don't call spi_atk_bridge_do_registration().

However, reverting the above change also means that we need to use a different mechanism for avoiding a crash if the registry IOR is not present on the root window - otherwise when dispatching the event notification we will segv.

So really, the 'success' boolean should depend on whether the registry IOR was present, and it should be checked and set even if we don't call spi_atk_bridge_register_application.  

Bill

Created attachment 81443 [details] [review]
this patch should fix things (warning, *untested* patch which builds OK)

Hi Bill.  Thanks so much for doing this!  I tested it on two of my machines.

The good news:  All of the events are back, which means Orca is providing access to the applets and menus again.  

The less-than-ideal news:  On one of my machines, I got a registry crash -- and this being a fresh install, I hadn't gotten around to installing debug libraries yet.  So.... I'll install those libraries on both boxes and get you a stack trace when and if it happens again.

Thanks again!

Bill,
I will test your patch when I get time.
Joanmarie,
It would be great you can give us trace with debug symbols. You can tell me the trace without debug symbols first. Maybe I can find the problem.

Created attachment 81515 [details]
at-spi-registryd crash file from /var/crash/

Hi Li.  I cannot yet cause the registry crash to happen at will, so I haven't been able to toss gdb at it.  It did crash a couple more times though.   In the spirit of "maybe it will help," I've attached the at-spi-registryd crash file from the last crash.  If that's what you need, great; otherwise, I'll keep trying to find a way to reproduce the problem reliably.

What I can tell you, however, is that each time the crash occurred after I quit Orca:  Once was immediately; the other times were very shortly thereafter.  It has never crashed while I was using Orca, nor does it usually crash when I quit Orca.

Hope this helps.  Thanks for looking into it!

Thank you for reporting this. I have found the trace:

+ Trace 106774

Seems the listener in at-spi-registryd's list has some bad values (probably orca, because orca is the only at I ran). And the signal is "window:destroy" (orca's window). So I guess the problem is Orca destroyed its data before it deregister its event listener?

Hi Bill, I tested your patch. at-poke can only receive "focus" signal the first time these embedded component get focus. I am trying to figure out why.

Oh, but for object:state-changed:focused, at-poke can receive every time.

Hi Li: All my patch does is revert a change introduced by bug 163132.  Maybe some other part of the code is responsible for the problem you are seeing?  Or even the panel (libpanelapplet?).

The 'focus:' problem sounds familiar to me, maybe this remaining issue is a duplicate of an existing bug...

(In reply to comment #12)
> Seems the listener in at-spi-registryd's list has some bad values (probably
> orca, because orca is the only at I ran). And the signal is "window:destroy"
> (orca's window). So I guess the problem is Orca destroyed its data before it
> deregister its event listener?
> 

In Orca, we're attempting to deregister all listeners before stopping the registry.  In the event that something terribly bad has happened, it may not be able to do so.

Do you think the thing described above would happen during normal operation of Orca?  That is, the bug in question happens while Orca is running and the user is attempting to navigate the top or bottom panels.  Would the thing described above happen during this scenario, or would it only happen when Orca quits?

> Do you think the thing described above would happen during normal 
> operation of Orca?  That is, the bug in question happens while Orca is 
> running and the user is attempting to navigate the top or bottom 
> panels.  Would the thing described above happen during this scenario, 
> or would it only happen when Orca quits?

I myself can only speak from experience, but it has never happened while using Orca, nor do the problems seem tied to navigating the panels.  While the first crash did occur after having used the panels (and then done some other things), that was not the case the other two times.

To follow-up on this:

The problem *seems* to have been introduced in at-spi revision 882.  I haven't narrowed it down further as it's pushing 4 AM and I really should sleep before work. :-)

Two tests: With revision 882 (or later) installed

1. Launch Orca, quit Orca, and try to launch at-poke.  at-poke won't launch.  ('Error initialising SPI').  BUT if you launch Orca again, you can then get at-poke to launch.

2a. Launch Orca from the Applications menu
2b. Launch Gedit and type "this is a test"
2c. Press KP_5 to flat review the current word. (Orca should say "test" and draw a rectangle around it)
2d. Quit Orca. 
2e. With the Gedit window focused, launch Orca from the Applications menu.  Type some additional text into Gedit and try KP_5 again.  Orca won't flat review the text as before. (If you Alt Tab out of the Gedit window and back into it, flat review resumes working).

With revision 881, I do not have the problems launching at-poke or using flat review.