Created attachment 71799 [details]
Orca debug generated whilst recreating this problem.

I've recreated what Mike is seeing. Attaching a full debug listing.
I'll hopefully have a few more comments in a few minutes...

Created attachment 71800 [details]
Orca debug generated whilst recreating this problem.

I've recreated what Mike is seeing. Attaching a full debug listing.
I'll hopefully have a few more comments in a few minutes...

When navigating up and down the lines in the Open Office
Writer document, there are now two events which are causing
each line to be spoken:

  object:state-changed:focused

and

  object:text-caret-moved

For example, in debug.out at line 5163 we get:

OBJECT EVENT: object:state-changed:focused             detail=(0,0)
    app.name='soffice.bin'        name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE'

which causes locusOfFocusChanged() in the StarOffice.py script to be called
(and process in section #1).

and at line 5194 we get:

OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
    app.name='soffice.bin'        name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE'

which is causing onCaretMoved() in default.py to be called, which in 
turn calls orca.setLocusOfFocus().

This is with Open Office v2.0.3.4-ubuntu2, from Tue August 1st at 13:11:16 UTC.

I'm going to compare this with running a recent StarOffice build against 
GNOME 2.14 on Solaris, to see what event(s) we are getting there for the 
same action.

I am seeing exactly the same events with StarOffice 8 Product Update 3 rev 2,
on GNOME 2.14 on Solaris with the latest version of Orca from CVS HEAD.
This too is generating the double speak.

Looks like the second half of the change of 10th August:

http://cvs.gnome.org/viewcvs/orca/src/orca/default.py?r1=1.190&r2=1.191

is causing the problem. If I comment out those three new lines in
onStateChanged(), the double speaking problem goes away.

Sorry, make that the change of 11th August (not the 10th).
The fix for bug #350854.

Well...darn.  These lines are needed for the gedit/metacity bug.  What do you think about creating a new onStateChanged method in the gedit script and moving these three lines to there?  The new method would look something like:

    def onSelectionChanged(self, event):
        """Called when an object's selection changes.

        Arguments:
        - event: the Event
        """

        if not event or not event.source:
            return

        # Avoid doing this with objects that manage their descendants
        # because they'll issue a descendant changed event.
        #
        if event.source.state.count(
                 atspi.Accessibility.STATE_MANAGES_DESCENDANTS):
            return

        default.Script.onSelectionChanged(self, event)

D'Oh.  Ignore the code snippet from the previous sample.  That's the problem with debugging three separate problems simultaneously.  :-(   Here's a better method for gedit.py that should work.  Again...the goal is to move the block of suspect code from default.py to gedit.py.  This will keep the gedit fix working, and restore the previous behavior for OOo (I hope):

    def onStateChanged(self, event):
        """Called whenever an object's state changes.

        Arguments:
        - event: the Event
        """

        # Sometimes an object will tell us it is focused this
        # way versus issuing a focus event.  GEdit's edit area,
        # for example, will do this: when you use metacity's
        # window menu to do things like maximize or unmaximize
        # a window, you will only get a state-changed event
        # from the text area when it regains focus.
        #
        if (event.type == "object:state-changed:focused") \
           and (event.detail1):
            orca.setLocusOfFocus(event, event.source)

        default.Script.onSelectionChanged(self, event)

OK - one more try:

        default.Script.onStateChanged(self, event)

Mental note: it's onStateChanged.  Not onSelectionChanged.

Thanks Will. I think I now have the correct code checked in
(see bug #350854 too). Closing as FIXED.