Does this happen only when running in the test harness (e.g., asyncMode=False)?

No.

In this situation, I would expect some sort of sequence of focus and active-descendant-changed events on the spreadsheet after you press return in step 4.

It may be that we get the focus event first and the active descendant changed event second.  I believe the focus event is what causes the presentation of information and the active descendant handler just helps do bookkeeping.  So, the ordering of events doesn't allow us to present the new active descendant appropriately.  

Rich, can you please investigate further and propose a solution?

Created attachment 96701 [details]
Orca debug output generated whilst reproducing this problem.

After typing "c3" into the cell locator and pressing Return, we get
the following events:

1. vvvvv PROCESS OBJECT EVENT object:text-selection-changed vvvvv
2. vvvvv PROCESS OBJECT EVENT object:text-selection-changed vvvvv
3. vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv
4. vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv
5. vvvvv PROCESS OBJECT EVENT object:selection-changed vvvvv
6. vvvvv PROCESS OBJECT EVENT object:selection-changed vvvvv
7. vvvvv PROCESS OBJECT EVENT object:state-changed:showing vvvvv
8. vvvvv PROCESS OBJECT EVENT object:state-changed:visible vvvvv
9. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
10. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
11. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
12. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
13. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
14. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
15. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
16. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
17. vvvvv PROCESS OBJECT EVENT object:active-descendant-changed vvvvv
18. vvvvv PROCESS OBJECT EVENT focus: vvvvv

These start at line 3298. 

Event 16. (at line 3454) is the one which causes the bogus braille and speech:

OBJECT EVENT: object:state-changed:focused             detail=(1,0)
    app.name='soffice'            name='Sheet Sheet1' role='table' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTISELECTABLE OPAQUE SELECTABLE SHOWING VISIBLE MANAGES_DESCENDANTS' relations=''

At line 3463, Orca thinks the LOCUS OF FOCUS is:

LOCUS OF FOCUS: app='soffice' name='Cell A1 ' role='table cell'
                event='object:state-changed:focused'
OBJECT EVENT: object:state-changed:focused             detail=(1,0)
             app.name='soffice'            name='Sheet Sheet1' role='table' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTISELECTABLE OPAQUE SELECTABLE SHOWING VISIBLE MANAGES_DESCENDANTS' relations=''

[The previous LOCUS OF FOCUS was the cell locator combo box (line 3448).]

This is coming from setLocusOfFocus() in orca.py.

If we add some debug and print a stack trace at that point, we get:

+ Trace 168001

The interesting bit of code that it passes through here, is in the onFocus()
method in default.py. At around line 2516 we have:

        # [[[TODO: WDW - HACK to deal with the fact that active cells
        # may or may not get focus.  Their parents, however, do tend to
        # get focus, but when the parent gets focus, it really means
        # that the selected child in it has focus.  Of course, this all
        # breaks when more than one child is selected.  Then, we really
        # need to depend upon the model where focus really works.]]]
        #
        newFocus = event.source

        if (event.source.role == rolenames.ROLE_LAYERED_PANE) \
            or (event.source.role == rolenames.ROLE_TABLE) \
            or (event.source.role == rolenames.ROLE_TREE_TABLE) \
            or (event.source.role == rolenames.ROLE_TREE):
            if event.source.childCount:
                # Well...we'll first see if there is a selection.  If there
                # is, we'll use it.
                #
                selection = event.source.selection
                if selection and selection.nSelectedChildren > 0:
                    newFocus = atspi.Accessible.makeAccessible(
                        selection.getSelectedChild(0))

                # Otherwise, we might have tucked away some information
                # for this thing in the onActiveDescendantChanged method.
                #
                elif event.source.__dict__.has_key("activeDescendantInfo"):
                    [parent, index] = event.source.activeDescendantInfo
                    newFocus = parent.child(index)

        orca.setLocusOfFocus(event, newFocus)

And this is the problem. This event is for a ROLE_TABLE object, there is
a child count, there is a selection but selection.nSelectedChildren is 0.
This means that it calls:

                # Otherwise, we might have tucked away some information
                # for this thing in the onActiveDescendantChanged method.
                #
                elif event.source.__dict__.has_key("activeDescendantInfo"):
                    [parent, index] = event.source.activeDescendantInfo
                    newFocus = parent.child(index)

Unfortunately that value for index is 0 (for cell A1).

Will, what's the best way to try to fix this?

One possibility would be to try to adjust the onFocus() method in the 
StarOffice.py script to check to see if the current locus of focus is
the cell locator combo box. If it is, and the new focus is a table, then
delete event.source.activeDescendantInfo (if it exists).

Does this seem a reasonable approach, or should we be trying for a more 
generic solution?

> After typing "c3" into the cell locator and pressing Return, we get
> the following events:
> 
> 16. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv
> 17. vvvvv PROCESS OBJECT EVENT object:active-descendant-changed vvvvv
> 18. vvvvv PROCESS OBJECT EVENT focus: vvvvv

It looks like 16 and 18 are the result of the same thing happening: the table regains focus, and 17 is the event that lets us know which cell is the one that is the active cell.

Earlier in the debug file, we see output for "A1" when we receive an object:active-descendant-changed event.  I'm not sure which logic triggered the output, but I suspect it might be the event.source.  For 17, I don't see any output, so I suspect event.any_data might be none.  If so, the locus of focus would be set to the table, which is most likely the same event source from event 16.  So, the locus of focus didn't change and nothing is output.

What I would expect from event 17 is that we would get an any_data that is Accessible of the new active child.  In this case, onActiveDescendantChanged would cause a change in locus of focus and speech would be output.  I wonder if we're not getting a proper event.any_data event 17 and this is YAOOB?  That is, I'd expect the any_data from event 17 to point to the accessible for C3.

> Event 16. (at line 3454) is the one which causes the bogus braille and speech:
> One possibility would be to try to adjust the onFocus() method in the 
> StarOffice.py script to check to see if the current locus of focus is
> the cell locator combo box. If it is, and the new focus is a table, then
> delete event.source.activeDescendantInfo (if it exists).

Do any of the events give us any pointer to the C3 cell?  If not, I wonder if we'd still speak A1 even after making the above change.

Created attachment 96879 [details]
Orca debug output with extra debug for "object:active-descendant-changed" events.

I added in some debug to onActiveDescendantChanged() in default.py
to print out the value of child (event.any_data), and if it was not None,
to print out it's role and name. 

For event #17 after the user has pressed Return after entering "c3" in 
the cell locator, we get (line 3515):

vvvvv PROCESS OBJECT EVENT object:active-descendant-changed vvvvv
OBJECT EVENT: object:active-descendant-changed         detail=(0,0)
    app.name='soffice'            name='Sheet Sheet1' role='table' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTISELECTABLE OPAQUE SELECTABLE SHOWING VISIBLE MANAGES_DESCENDANTS' relations=''
>>>>onActiveDescendantChanged: child:  <orca.atspi.Accessible instance at 0x11f24d0>
>>>>onActiveDescendantChanged: child: name:  Cell A1
>>>>onActiveDescendantChanged: child: role:  table cell
^^^^^ PROCESS OBJECT EVENT object:active-descendant-changed ^^^^^

Event #18 (the "focus:" event), is for the spread sheet table (same as
event #16), so nothing happens there.

I think you are right. This looks like YAOOOB. If you concur, I'll file it.

Thanks.

> vvvvv PROCESS OBJECT EVENT object:active-descendant-changed vvvvv
> OBJECT EVENT: object:active-descendant-changed         detail=(0,0)
>     app.name='soffice'            name='Sheet Sheet1' role='table'
> state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTISELECTABLE OPAQUE SELECTABLE
> SHOWING VISIBLE MANAGES_DESCENDANTS' relations=''
> >>>>onActiveDescendantChanged: child:  <orca.atspi.Accessible instance at 0x11f24d0>
> >>>>onActiveDescendantChanged: child: name:  Cell A1
> >>>>onActiveDescendantChanged: child: role:  table cell
> ^^^^^ PROCESS OBJECT EVENT object:active-descendant-changed ^^^^^

Yeah - it definitely looks like a bug.  It doesn't seem like there's a way for us to determine that we're on Cell C3.

> I think you are right. This looks like YAOOOB. If you concur, I'll file it.

Please do.  Thanks for digging into this!

I've opened OOo issue #82409 against this problem:
http://www.openoffice.org/issues/show_bug.cgi?id=82409

Blocking this one.

OpenOffice.org issue 82409 fixed for target OOo 2.4

Unblocking since the blocking bug has been marked as fixed (THANKS Daniel!).

The problem still exists.

Tried with the latest Linux RPM's compressed tarball from
http://download.openoffice.org/680/index.html
Unfortunately there is no version number on the Help->About
dialog. It just says "OOo-dev 2.4.0". The directory it unpacked
into (before I installed it) was SRC680_m241_native_packed-1_en-US.9244

http://www.openoffice.org/issues/show_bug.cgi?id=82409
says it was fixed in SRC680/dr58 (OOo 2.4). Unclear how
that equates to OOo dev-builds. 

Daniel, maybe you can help here? ...

The OOo issue 82409 is part of the childworkspace (CWS) "dr58", see
http://tools.services.openoffice.org/EIS2/cws.ShowCWS?Id=5919&OpenOnly=false&Section=All

This CWS still has status "new". It will be integrated before OOo 2.4. When this is done, the field "Milestone (integrated)" will show the first milestone of the SRC680 code line that contains the bugfix, let's say m250. After integration, the developer build SRC680_m250_native_packed-1_en-US.???? will contain the bugfix.

Hope this helps
Daniel

It does indeed. Thanks Daniel.

I've just downloaded and installed the latest  Linux RPM's 
compressed tarball from
http://download.openoffice.org/680/index.html

The directory it unpacked into (before I installed it) 
was SRC680_m241_native_packed-1_en-US.9254

I can firm the problem in now fixed, and using the steps
above, Orca successfully speaks "c3".