Mike says he can confirm this.  Joanie suspects they may have changed the hierarchy.

I think ive tracked down this to be one of ours.
svn trunk rev 3915 is fine, svn trunk rev 3916 is not.
It would be good if you could confirm that at rev3915 things work as you expect.

I first noticed this because when left clicking on the wireless applet, Orca does not read out the available wireless networks.

Thank you

Thanks Jon.  Rev 3916 caused a traceback which was fixed by rev 3920 and then the whole fix was reversed completely in rev 3923 due to another issue and then a new fix was later.... yadda, yadda, yadda.  In other words, things indeed weren't fine in rev 3916. :-)  Still investigating....

Rev 3951 works; 3952 doesn't.  So it is that bug/fix....

Thanks Joanie,
ok, but 3916 also must have broken something else then:
right clicking on the wireless applet, we are fine reading the menu items.
left clicking on the other hand we are no longer reading the menu items.
3915 left clicking reads menu items fine.

So i assume the bug im describing here is a diffrent bug alltogether?

Rich, in rev 3952 this block was added to orca.py:

    # If this event is not for the currently active script, then just return.
    #
    if event and event.source and \
       event.host_application and orca_state.activeScript:
        currentApp = orca_state.activeScript.app
        if currentApp != event.host_application and \
           currentApp != event.source.getApplication():
            return

I commented out the return line and put a print line in its place and we suddenly started speaking focused applets (and printing).  Given the complexity of that fix and that you wrapped your head around it while I'll did not....

Could you please be persuaded to take this one? :-)

(In reply to comment #5)
> Thanks Joanie,
> ok, but 3916 also must have broken something else then:

Yup! 3916 caused tracebacks and cause several things to stop speaking.  Then it was adjusted.  Ultimately it was reversed.  That code is gone. <smile>

As for if what you're seeing is a different bug or not:

1. Can you reproduce your bug in the current trunk? If so:
2. Can you reproduce your bug in rev 3952 but not 3951?

If the answer to those questions is "yes," then I would call your bug the same bug or a variant thereof; otherwise, I'd call your bug a different bug.

(In reply to comment #7)
> 1. Can you reproduce your bug in the current trunk? If so:
> 2. Can you reproduce your bug in rev 3952 but not 3951?

yep, seems to be same or varient. Indeed 3951 left clicking reads the available network list fine, and 3952 does not. We are still unable to read the list in rev 3986. 

W.r.t. Joanie's investigation in comment #6, the only thing I can
think of is, we add another check box on the General tab of the 
Orca preferences to indicate whether we want to process events 
that are not for the current applicvation. 

Will, what would you like done here?

Thanks!

(In reply to comment #9)
> W.r.t. Joanie's investigation in comment #6, the only thing I can
> think of is, we add another check box on the General tab of the 
> Orca preferences to indicate whether we want to process events 
> that are not for the current applicvation. 
> 
> Will, what would you like done here?

More investigation, please.  What events are we getting in this case?  What is the current active script?  Is there some event we're getting that would let us set the active script appropriately?

Created attachment 112991 [details]
Orca debug log generated whilst testing this problem.

I added two applets to the bottom panel:

1/ Dictionary.
2/ Weather.

I then used Control-Alt-Tab to move focus to the bottom panel.
It gave focus to the dictionary applet.

I then Tabbed to the weather applet.

> What events are we getting in this case?

See attached Orca debug log. There are some extra debug lines printing
out useful information. See comment #16 to bug #530368:
http://bugzilla.gnome.org/show_bug.cgi?id=530368#c16
for what those are.

Tabbing to the weather applet gave the following events:

line 401:
OBJECT EVENT: object:state-changed:focused             detail=(0,0)
    app.name='gnome-dictionary-applet' name='Dictionary entry' role='text' state='editable enabled focusable focused sensitive showing single line visible' relations=''

line 428:
OBJECT EVENT: object:state-changed:focused             detail=(1,0)
    app.name='gweather-applet-2' name='GNOME Weather' role='embedded component' state='enabled focusable focused sensitive showing visible' relations=''

line 466:
OBJECT EVENT: object:state-changed:focused             detail=(0,0)
    app.name='gnome-dictionary-applet' name='None' role='panel' state='enabled resizable sensitive showing visible' relations=''

line 481:
OBJECT EVENT: object:state-changed:focused             detail=(1,0)
    app.name='gweather-applet-2' name='None' role='panel' state='active enabled resizable sensitive showing visible' relations=''

> What is the current active script?

setLocusOfFocus was only called for the second one:

XXX: orca_state.activeScript.app.name:  gnome-panel
XXX: event.host_application.name:  gweather-applet-2
XXX: event.source.getApplication().name:  gweather-applet-2

> Is there some event we're getting that would let us
> set the active script appropriately?

I'm not sure.

Sorry, Will forgot to add your name on again.

To debug this further, I made some simple modifications to orca.py to better understand what it going on:

bash-3.2$ svn diff src/orca/orca.py
Index: src/orca/orca.py
===================================================================
--- src/orca/orca.py    (revision 3990)
+++ src/orca/orca.py    (working copy)
@@ -189,6 +189,16 @@
         currentApp = orca_state.activeScript.app
         if currentApp != event.host_application and \
            currentApp != event.source.getApplication():
+            print "ACTIVE SCRIPT:", orca_state.activeScript.name
+            print "CURRENT APP", currentApp
+            print "EVENT APP", event.host_application
+            print "SOURCE ANCESTRY"
+            orca_state.activeScript.printAncestry(event.source)
+            print "EVENT APP HIERARCHY"
+            orca_state.activeScript.printHierarchy(event.host_application,
+                                                   event.source)
+            print "EVENT APP ANCESTRY"
+            orca_state.activeScript.printAncestry(event.host_application)
             return
 
     oldLocusOfFocus = orca_state.locusOfFocus

Here's an example output:

ACTIVE SCRIPT: gnome-panel (module=orca.scripts.gnome-panel)
CURRENT APP [application | gnome-panel]
EVENT APP [application | trashapplet]
SOURCE ANCESTRY
+- app.name='gnome-panel' name='gnome-panel' role='application' state='' relations=''
  +- app.name='gnome-panel' name='Bottom Expanded Edge Panel' role='frame' state='active enabled resizable sensitive showing visible' relations=''
    +- app.name='gnome-panel' name='None' role='panel' state='enabled sensitive showing visible' relations=''
      +- app.name='gnome-panel' name='None' role='panel' state='enabled sensitive showing visible' relations=''
        +- app.name='gnome-panel' name='Bottom Expanded Edge Panel' role='panel' state='enabled sensitive showing visible' relations=''
          +- app.name='gnome-panel' name='None' role='panel' state='enabled sensitive showing visible' relations=''
            +- app.name='gnome-panel' name='None' role='panel' state='enabled sensitive showing visible' relations=''
              +- app.name='trashapplet' name='None' role='panel' state='active enabled resizable sensitive showing visible' relations=''
                +- app.name='trashapplet' name='None' role='embedded component' state='enabled focusable focused sensitive showing visible' relations=''
EVENT APP HIERARCHY
+- app.name='trashapplet' name='trashapplet' role='application' state='' relations=''
EVENT APP ANCESTRY
+- app.name='trashapplet' name='trashapplet' role='application' state='' relations=''

What this is saying is that from the event.source hierarchy point of view, 'trashapplet' is *not* a top level object, which is what we expect applications to be.  Instead, it is nested in the gnome-panel hierarchy.  On the other hand, we see a 'trashappplet' application for event.host_application, but it doesn't appear in the event.source hierarchy.  Very strange.

We might try taking advantage of this oddity, but I think we need clarification from Li about why we're running into this strange behavior with applets.  Adding Li to the CC list.

Created attachment 113046 [details] [review]
Hack to set active script under special conditions

This is a hack to check for the special applet application condition (i.e., host application has no children).  We still should wait to hear from Li about whether this special condition is expected or not.  In addition, some additional work might be needed to speak more information -- with this patch, the trash applet is just spoken as "embedded component" for example.

Sorry, I am working on some other bugs today. I will look at this once I get time tomorrow.

In atk_bridge_init, we can see if the applet is a bonobo component (like trash), atk-bridge will not register it. libgail-gnome will handle the accessibility communication between gnome-panel and the applet. So it seems as it is not top level object and is nested in the gnome-panel hierarchy. But it still has its own application name...

This is different with notification area icons which are implemented by gtkstatusicon.

(In reply to comment #16)
> In atk_bridge_init, we can see if the applet is a bonobo component (like
> trash), atk-bridge will not register it. libgail-gnome will handle the
> accessibility communication between gnome-panel and the applet. So it seems as
> it is not top level object and is nested in the gnome-panel hierarchy. But it
> still has its own application name...

What do you think is the appropriate thing to do here?  I recall Bill may have had some very strong opinions about the subject and I recall him sighing heavily many times about the difficulties of handling these beasts.

If we leave the AT-SPI implementation as is, Orca can easily check for the odd hierarchy and handle it.  It would also allow us to more easily support custom scripts on a per-applet basis.  But, the hierarchy definitely is strange (i.e., the application has no children).

> This is different with notification area icons which are implemented by
> gtkstatusicon.

I'm not sure what you are describing here.  When I tab to the notification area, it is treated like the other applets (i.e., the odd hierarchy).  When I then tab or arrow into the notification area, however, they seem to show up nicely as children of the notification applet.

Li, do you think it is acceptable to leave the AT-SPI implementation as is?  It might be the easiest thing for us to handle, even if it is strange.

(In reply to comment #17)
> (In reply to comment #16)
> > In atk_bridge_init, we can see if the applet is a bonobo component (like
> > trash), atk-bridge will not register it. libgail-gnome will handle the
> > accessibility communication between gnome-panel and the applet. So it seems as
> > it is not top level object and is nested in the gnome-panel hierarchy. But it
> > still has its own application name...
> What do you think is the appropriate thing to do here?  I recall Bill may have
> had some very strong opinions about the subject and I recall him sighing
> heavily many times about the difficulties of handling these beasts.
> If we leave the AT-SPI implementation as is, Orca can easily check for the odd
> hierarchy and handle it.  It would also allow us to more easily support custom
> scripts on a per-applet basis.  But, the hierarchy definitely is strange (i.e.,
> the application has no children).

Since the applet is implemented by bonobo, I suggest we just leave it there. If they transfer to DBus, there should not be such problem.
> > This is different with notification area icons which are implemented by
> > gtkstatusicon.
> I'm not sure what you are describing here.  When I tab to the notification
> area, it is treated like the other applets (i.e., the odd hierarchy).  When I
> then tab or arrow into the notification area, however, they seem to show up
> nicely as children of the notification applet.

Yes. I meant the notification area applet belongs to its own application which should register to at-spi-registryd. So events should be sent out by the host application (like tracker-applet). gnome-panel sends out events at the same time, I am not sure which one is Orca listening to. Anyway, there should not be the "mismatch" of app.name in this case.

Thanks Li!  Committed the existing patch, which looks for the applet application anomaly, to trunk for 2.23.5.  Closing as FIXED.

From private e-mail, Kenny let me know this fix may have broken things:

"If someone has filed a bug about read line sudenly reading the pannel instead of the app with focus, it's the result of the fix for 536985."

So, I'm going to re-open this and I'm marking it as NEEDINFO as an indicator for Kenny to help give us a test case for reproducing the problem.

I took a long hard look at this today.  The problem is the result of a couple things competing:

1) The patch for this bug sets the active script if it detects the special hierarchy in lucky comment #13

2) The patch for bug #530368 prevents us from setting the locus of focus if the current app is not the active script

So...let's take the following use case:

0) Run Orca

1) Ctrl+Alt+Tab to the bottom panel (the one with the trash applet in it)

2) Arrow right across the various things on the bottom panel, such as the toggle buttons for the apps and the workspace switcher.  Orca should speak them and it thinks the active script is for gnome-panel.

3) Arrow one more time to the trashapplet.  This beast has the strange hierarchy from comment #13.  As a result, the patch for this bug ends up making a new trashapplet script and making it the active script.

4) Arrow back off the trashapplet.  We get object:state-changed:focus events for the objects in the gnome-panel that you went across in #2, but we don't get an event to tell us to activate the gnome-panel script.  So, in Orca's eyes, these events are not coming from the active script.

So...for how to fix this?  I'm not sure.  The original motivator for bug #530368 was bug #523731, which was probably caused by text inserted events and other non-focus-like things.  I'm wondering if we need to make another case to set the active script (and only reset it if it's not the currently active script) if we detect events that indicate something just got focus.

Created attachment 115594 [details] [review]
Patch to set active script on focus gained events and to eliminate embedded rolename from speech and braille

This patch seems to solve the regression and it also pylints and tests well.  There are still problems with notification area presentation, but that can be handled as part of bug #431030.

This seems to now work as described.  

Created attachment 115707 [details] [review]
Revised patch to actually include the braille fixes

The problem of ORca not reading the applet on the pannel is now fixed with the latest attachment.  however, the focus problem still exists.  The behavior is as follows:  Flat review will suddenly be unable to read the contents of the app with focus.  Where am i (keypad enter) will still be correct, keys will still effect the app with focus, but flat review keys like read word, line, or char will read "blank'.  An alt-tab is required to get flat review working again.  The problem appears to happen when something on a pannel updates.

(In reply to comment #25)
> The problem of ORca not reading the applet on the pannel is now fixed with the
> latest attachment.  however, the focus problem still exists.  The behavior is
> as follows:  Flat review will suddenly be unable to read the contents of the
> app with focus.  Where am i (keypad enter) will still be correct, keys will
> still effect the app with focus, but flat review keys like read word, line, or
> char will read "blank'.  An alt-tab is required to get flat review working
> again.  The problem appears to happen when something on a pannel updates.

Hey Kenny!  Nice to hear from you.  It sounds as though some app is grabbing focus.  When this happens, can you press Orca+Ctrl+Alt+Home?  It will present information about the currently active script, application, and toolkit.

The first time it happened: default script weather-applet2 module orca.scripts.toolkits.gail application name gnome-terminal toolkit name gail version 1.22.1
second time: script update notifier module orca.scripts.toolkits.gail application gnome-terminal toolkit name gail version 1.22.1
I couldn't figure out a way to copy the info to the clipboard, so the info is written down from a audio recording.  The names are correct, but the exact spelling and punctuation isn't.

(In reply to comment #27)
> The first time it happened: default script weather-applet2 module
> orca.scripts.toolkits.gail application name gnome-terminal toolkit name gail
> version 1.22.1

Thanks for grabbing this!  Wow...something is getting very confused, and I'm have a really hard time reproducing it.  Can you tell me more about:

1) Which OS distribution and version you are using?

2) Which version of Orca you are using and/or if there is anything customized about your installation (e.g., did you build/install any GNOME/AT-SPI components from sources)?

3) A detailed example of what you were doing when this happened.  A debug.out file would also be very useful.  What I've been trying to do is give gnome-terminal focus and keep flat reviewing it while I unplug my power supply, send myself chats from another machine, etc.  I cannot seem to reproduce the problem.  :-(

System: Ubuntu Hardy (8.04) updated to current over the internet.
The only app built from source on the system is orca.  Orca version svn rev 4074.
I'm not doing anyting special.  The problem happens every time the weather applet updates or I do something like an upgrade that causes the update notifier to update.
What I mean is the problem always happens after an aptitude dist-upgrade actually upgrades packages.  Just wait a minute or so after the upgrade finishes and the problem happens.  I got it to occur while writing this because tzdata was updated in the other window.

almost forgot: I havent' seen the problem while using flat review.  It usually happens while using an app.  When I stop getting output from the app, I will then see the flat review behavior.
(In reply to comment #29)
> System: Ubuntu Hardy (8.04) updated to current over the internet.
> The only app built from source on the system is orca.  Orca version svn rev
> 4074.
> I'm not doing anyting special.  The problem happens every time the weather
> applet updates or I do something like an upgrade that causes the update
> notifier to update.
> What I mean is the problem always happens after an aptitude dist-upgrade
> actually upgrades packages.  Just wait a minute or so after the upgrade
> finishes and the problem happens.  I got it to occur while writing this because
> tzdata was updated in the other window.
> 

Created attachment 116008 [details] [review]
Patch to back out the nasty hack from comment #14.

This patch effectively backs out the nasty hack from comment #14.  The things I'm seeing that don't speak are ill-behaved applets that are out of our control, such as the "Configure display settings" and "User switcher" applets.  We might be able to hack more, but we can certainly see this is a delicate space to hack.

Thanks!  We will use bug #431030 to track the other issues with navigation and not being able to get text to present.