Created attachment 107551 [details]
Orca debug output whilst testing this problem.

First comment is that looking at the accessible component hierarchy
of this dialog with accerciser just shows the dialog with one child;
the "Search For" label. That seems broken.

I added in a little debug to the StarOffice.py script to print out
the component ancestry for "focus:" events. For those two related to
the Find and Replace dialog, we get:
+- app.name='soffice' name='soffice' role='application' state='' relations=''
  +- app.name='soffice' name='Find & Replace' role='dialog' state='active enabled sensitive showing visible' relations=''
    +- app.name='soffice' name='Search for' role='combo box' state='enabled sensitive showing visible' relations='labelled by'
      +- app.name='soffice' name='Search for' role='text' state='editable enabled focusable focused sensitive showing single line visible' relations='labelled by'

and

+- app.name='soffice' name='soffice' role='application' state='' relations=''
  +- app.name='soffice' name='Find & Replace' role='dialog' state='active enabled sensitive showing visible' relations=''
    +- app.name='soffice' name='Replace with' role='combo box' state='enabled sensitive showing visible' relations='labelled by'
      +- app.name='soffice' name='Replace with' role='text' state='editable enabled focusable focused sensitive showing single line visible' relations='labelled by'

So we are in a text field inside a combo box. Those text fields have 
"labelled by" relationships, presumably with the labels to just above
them.

I now need to dig deeper and find out why they aren't being spoken.

The problem is that in the onFocus() method in StarOffice.py,
there is the following piece of code:

    def onFocus(self, event):
        """Called whenever an object gets focus. Overridden in this script
        so that we can adjust "focus:" events for children of a combo-box
        to just set the focus to the combo box. This is needed to help
        reduce the verbosity of focusing on the Calc Name combo box (see
        bug #364407).

        Arguments:
        - event: the Event
        """

        if event.source.parent.getRole() == pyatspi.ROLE_COMBO_BOX:
            orca.setLocusOfFocus(None, event.source.parent, False)
            return

If I comment that out, it does the right thing. Looks like I'll
need to add more code to force it just to return when in the Calc
Name combo box.

Created attachment 107559 [details] [review]
Revision #1.

The attached patch now looks for a specific component hierarchy
in the onFocus() method in StarOffice.py, before adjusting to
do a orca.setLocusOfFocus() on the parent (i.e the Calc Name combo
box).

This now allows the two oowriter Find and Replace combo box lists
to be spoken.

Looking at bug #364407 (Shift+Ctrl+T in OOCalc results in very 
verbose output), I notice that I originally filed OOo issue #70955
http://www.openoffice.org/issues/show_bug.cgi?id=70955
against this problem, but asked them to close it because we were 
falling back on speaking the accessible description if there was 
no accessible name. I'm wondering now whether that was a mistake 
and we should ask them to give an accessible name to this component.
At the moment, with this patch, when we do Control-Shift-t to move 
to the Calc Name combo box, it speaks nothing.

Thoughts?

Mike, please test.

This now seems to work.  thanks much 

Thanks Mike. Patch committed to SVN trunk and the gnome-2-22 branch.
Moving to "[pending]".

We still have the open question about what (if anything) we want to
do about the accessible name for the Calc Name combo box. See 
comment #3 for more details.

(In reply to comment #3)
> no accessible name. I'm wondering now whether that was a mistake 
> and we should ask them to give an accessible name to this component.
> At the moment, with this patch, when we do Control-Shift-t to move 
> to the Calc Name combo box, it speaks nothing.

I think we definitely want to present something when the focus shifts from the table to the combobox.  I'm not sure I understand exactly where we were and where we are now, though.  Is this behavior a regression?

Depends what you mean by regression. Without the "fix" for bug #364407,
Orca spoke the accessible description for that component which was
very verbose. With the fix it speaks nothing when you Control-Shift-t
to the Name combo box in oocalc. As mentioned, there is no accessible
name currently associated with that component.

(In reply to comment #7)
> Depends what you mean by regression. Without the "fix" for bug #364407,
> Orca spoke the accessible description for that component which was
> very verbose. With the fix it speaks nothing when you Control-Shift-t
> to the Name combo box in oocalc. As mentioned, there is no accessible
> name currently associated with that component.
> 

Presenting *something* when the focus changes is probably preferred, but the really verbose output is bad.  I'm guessing getting the OOo folks to set the name of the combobox, list, and text area to "Name Box" (the tooltip I see when I hover over the beast) would probably be the best option.

But, I'm still curious why we aren't presenting anything, such as at least the role name.

Created attachment 107645 [details] [review]
Patch #2

> But, I'm still curious why we aren't presenting anything, 
> such as at least the role name.

Will and I discussed this a little while ago. The way I was doing
this (by setting 'event.source.name = _("Move to cell")' in section #5
of the locusOfFocusChanged() method in StarOffice.py won't work in
the pyatspi world.

The code has been revamped. Now, when you Control-Shift-t to the oocalc
Name combo box you get:
BRAILLE LINE:  'soffice Application Untitled1 - OpenOffice.org Calc Frame Untitled1 - OpenOffice.org Calc RootPane ToolBar List'
     VISIBLE:  'List', cursor=1
SPEECH OUTPUT: 'Move to cell'

I've also updated the regression test for this bug to reflect these changes.

New patch not checked in yet. 

Please test.

I've gone ahead and checked the second patch in as it's going to be
needed to fix bug #523466 (or close as a duplicate). Moving to "[pending]".

*** Bug 523466 has been marked as a duplicate of this bug. ***

This one seems to be working well.  thanks