Oops, forgot a test case.  Rich's test document from SayAll illustrates the issue: http://bugzilla.gnome.org/attachment.cgi?id=85811&action=view

I just tried Control-Up and Control-Down with the "say all" 
document in OOo Writer with latest Orca.

For me, nothing is spoken and when I do Control-up/Down the cursor is
moving up/down the document but the paragraphs are moving too.

Joanie, can you attach a full debug to this bug report please?

For extra bonus points, can you go first go into Staroffice.py and
change line 673 from:

        self.debugLevel = debug.LEVEL_FINEST

to:

        self.debugLevel = debug.LEVEL_OFF

then uncomment each occurrence of 


# self.printAncestry(event.source)

(lines 1418, 1698, 1741 and 1949), then generate the debug.out
file.

Thanks.

Created attachment 87420 [details]
debug.out requested by Rich

> For me, nothing is spoken and when I do Control-up/Down the cursor is
> moving up/down the document but the paragraphs are moving too.

That's how it always used to be.  I don't know at what point it changed -- stumbled across it by accident today.  But this is now true both with the 32-bit and 64-bit versions of OOo 2.2 that come with Feisty.  I'm wondering if those keyboard settings get stored in one's home directory and doing completely fresh installs recently has resulted in my having new keystrokes rather than older, inherited ones.  Regardless....

> Joanie, can you attach a full debug to this bug report please?

Done.

> For extra bonus points, can you go first go into Staroffice.py and
> change line 673 from:
> 
>         self.debugLevel = debug.LEVEL_FINEST
> 
> to:
> 
>         self.debugLevel = debug.LEVEL_OFF

Done.

> then uncomment each occurrence of 
> 
> 
> # self.printAncestry(event.source)

Here's what wound up in the terminal window after using Control Down to go from paragraph to paragraph to the end of the SayAll sample followed by Control Up to work back up to the top:

+-name='soffice.bin' role='application' state='' relations=''
  +-name='sample - OpenOffice.org Writer' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations=''
+-name='soffice.bin' role='application' state='' relations=''
  +-name='sample - OpenOffice.org Writer' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations=''

(yup, that's all of it)

> That's how it always used to be.  I don't know at what point it changed --
> stumbled across it by accident today.  But this is now true both with the
> 32-bit and 64-bit versions of OOo 2.2 that come with Feisty.  I'm wondering if
> those keyboard settings get stored in one's home directory and doing completely
> fresh installs recently has resulted in my having new keystrokes rather than
> older, inherited ones.

It must be something like this. I believe I'm using the latest version of OOo
2.2 on Feisty and I'm not seeing what you are seeing.

Thanks for the debug output. From this I can see that for each
Control-Down, it appears to generate two object:text-caret-moved events:

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' relations='FLOWS_FROM FLOWS_TO'

...

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

each of which caused the same line to be spoken/brailled. It seems it's
all in the details. In this case (0,0) and (-1,0).

Perhaps we should be checking for a certain value in event.detail1, like
we do in some of the methods in default.py before we speak/braile the line. 
This would be in onCaretMoved. I think the StarOffice.py is falling through 
to the one in default.py, so maybe that's where this logic needs to go
(or in default._presentTextAtNewCaretPosition()).

It still needs more investigating. I'll continue looking at it tomorrow 
(unless you beat me to it Joanie) :-)

Yup, removing my ~/.openoffice.org2 directory now gives me
the Control-Up/Down fuctionality you are seeing.

> Yup, removing my ~/.openoffice.org2 directory now gives me
> the Control-Up/Down fuctionality you are seeing.

Thanks for the confirmation.  You know, after this bug gets resolved, it might be worth passing along the above tip to the list.  People coming from the Windows world are very much used to being able to use Control-Up/Down to navigate by paragraph and they'll probably be happy to have that functionality (back) in Writer.

Created attachment 87465 [details]
Simpler test document to use.

I've trimmed down the "say all" document to just contain
four short paragraphs.

Created attachment 87466 [details]
Orca debug output when testing with new sample.odt

What I'm finding here is that it's not speaking most of the
paragraphs at all as I move around with Control-Down/Up. The
exceptions seem to be the first and last and then not always.

This seems to be different from what you were getting Joanie.

Still investigating.

Created attachment 87471 [details]
Another Orca debug output file (with extra added print statements).

Yummy! Well this is getting interesting.

If I quickly press Control-Up/Down together (i.e. almost at
the same time), I get no speech output as I navigate between
the paragraphs.

If I hold the Control key down for say at least a second before
I then also press the Up/Down key, I hear multiple utterances of that
paragraph spoken.

Don't you just love timing problems...

Still investigating.

Let's concentrate on the multiple speech utterances.

What's happening is that we are getting multiple "object:text-caret-moved"
events for each paragraph. 

Here's an example.

From latest OOo-debug.out:

Line 1336:
vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv
OBJECT EVENT: object:text-caret-moved                  detail=(132,0)
Speaks line.

----

Line 1378:
vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv
OBJECT EVENT: object:text-caret-moved                  detail=(-1,0)
Speaks line.

----

Line 1425:
vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv
OBJECT EVENT: object:text-caret-moved                  detail=(-1,0)
Doesn't speak line. This is caught in onCaretMoved() in default.py

        # Ignore caret movements from non-focused objects, unless the
        # currently focused object is the parent of the object which
        # has the caret.
        #
        if (event.source != orca_state.locusOfFocus) \
            and (event.source.parent != orca_state.locusOfFocus):
            return

----

Line 1444:
vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv
OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
Speaks line.

----

Any suggestions on how to "just pick one" here would be most welcome.

Created attachment 87821 [details] [review]
Patch to ignore detail1 == -1 in onCaretMoved.

Will and I talked about this bug this morning. He suggested
ignoring the "object:text-caret-moved" events if detail1 was -1.
This has improved things (see new debug output to be attached),
but we are still sometimes getting two "object:text-caret-moved"
events still per move: one with a detail of 0 the other with a
large positive number (which I've been presuming was the number
of characters in the text -- still to be confirmed). Note that
as I move Control-Up/Down, visually the text caret is at the
beginning of the line each time.

I'm now going to experiment with just moving Up/Down (not Control-Up/Down)
and also ignoring any "object:text-caret-moved" events unless the detail1
is zero for Control-Up/Down movements.

Created attachment 87822 [details]
Orca debug generated while testing with the last attached patch.

Created attachment 87823 [details] [review]
Revised version of the previous patch to remove debug messages.

I've committed the patch. It certainly improves things.
I'm occasionally still getting the odd line spoken twice.
I'm also getting the "no speech" problem mention in 
comment #9. Is anybody else getting that as well?

Here's what's happening when no spech is output when I
Control-Down really fast (i.e. don't hold the Control
key down for a second before I hit the Down key):

We are getting the following four key events:

KEYEVENT: type=0
          hw_code=37 
          modifiers=0
          event_string=(Control_L)
          is_text=True
          time=1178644842.891697

KEYEVENT: type=0
          hw_code=104
          modifiers=4
          event_string=(Down)
          is_text=True
          time=1178644843.003793
...
KEYEVENT: type=1
          hw_code=104
          modifiers=4
          event_string=(Down)
          is_text=True
          time=1178644843.037054

KEYEVENT: type=1
          hw_code=37
          modifiers=4
          event_string=(Control_L)
          is_text=True
          time=1178644843.050166

[processing of "object:text-caret-moved" events.]

When we are in _presentTextAtNewCaretPosition() in default.py,
we test if orca_state.lastInputEvent.event_string is a variety
of things like "Up", "Down", "Left", "Right" and so on. Nothing
is matched because the last event_string in this case is "Control_L".

Now if we slow things down and make sure we release the
Control key a little time after we release the Down arrow, we get:

KEYEVENT: type=0
          hw_code=37
          modifiers=0
          event_string=(Control_L)
          is_text=True
          time=1178645515.270102

KEYEVENT: type=0
          hw_code=104
          modifiers=4
          event_string=(Down)
          is_text=True
          time=1178645515.860954
...
KEYEVENT: type=1
          hw_code=104
          modifiers=4
          event_string=(Down)
          is_text=True
           time=1178645515.937434

[processing of "object:text-caret-moved" events.]

KEYEVENT: type=1
          hw_code=37
          modifiers=4
          event_string=(Control_L)
          is_text=True
          time=1178645516.345809

Will, any suggestions on what we should do here?

It's a pity we can't tie a KEY event to the accessibility events that
it generates.

> When we are in _presentTextAtNewCaretPosition() in default.py,
> we test if orca_state.lastInputEvent.event_string is a variety
> of things like "Up", "Down", "Left", "Right" and so on. Nothing
> is matched because the last event_string in this case is "Control_L".

Ah...bummer.

> Will, any suggestions on what we should do here?

I'm not sure.  We might consider doing something like keeping track of the last non-modifier key event in addition to the last key event (e.g., maybe orca_state.lastPrintableKey) and then using that.  Another possibility may be to think about inferring movement in a whole different way: keep track of the last caret position and infer movement based upon how far the caret jumped.

> It's a pity we can't tie a KEY event to the accessibility events that
> it generates.

The lack of being able to create a group of a11y events related to a single user input action has been a long standing criticism of mine.  It goes back to even the time when we worked on RAP back in the early 90's.  :-( 

Created attachment 87956 [details] [review]
Patch to add in orca_state.lastNonModifierKeyEvent

Wow! This turned into a big one. I haven't committed it yet
as I want feedback from others first.

Here's the entry from the ChangeLog file:

        * src/orca/scripts/gedit.py:
          src/orca/scripts/gcalctool.py:
          src/orca/scripts/gnome-terminal.py:
          src/orca/scripts/acroread.py:
          src/orca/scripts/Evolution.py:
          src/orca/scripts/StarOffice.py:
          src/orca/orca.py:
          src/orca/default.py:
          src/orca/focus_tracking_presenter.py:
          src/orca/Gecko.py:
          src/orca/orca_state.py:
          Hopefully fixed the "no speech" problem related to bug #435201,
          because we were getting the key events in a different order.
          We now save a handle to the last non-modifier key event in
          orca_state.lastNonModifierKeyEvent, and use that in
          _presentTextAtNewCaretPosition() to check what type of modified
          key event we currently have.

          Note that there were numerous other places where a similar
          problem could have existed.

I grepped for usage of "orca_state.lastInputEvent.event_string"
in all the Orca source files and the files in the scripts directory. 

I got the following:

default.py:1548:        lastKey = orca_state.lastInputEvent.event_string
default.py:1723:            and orca_state.lastInputEvent.event_string == "Right":
default.py:1747:        if orca_state.lastInputEvent.event_string == "Right":
default.py:1754:        elif orca_state.lastInputEvent.event_string == "Left":
default.py:2362:        string = orca_state.lastNonInputEvent.event_string
default.py:2528:        string = orca_state.lastInputEvent.event_string
default.py:2618:            keyString = orca_state.lastInputEvent.event_string
default.py:2755:                    and (orca_state.lastInputEvent.event_string == "F1"):
default.py:5380:            eventStr = orca_state.lastInputEvent.event_string
focus_tracking_presenter.py:427:                    if not orca_state.lastInputEvent.event_string == "F1":
Gecko.py:2212:            string = orca_state.lastInputEvent.event_string
gnomespeechfactory.py:675:            lastKey = orca_state.lastInputEvent.event_string
acroread.py:375:                lastKey = orca_state.lastInputEvent.event_string
acroread.py:631:            lastKey = orca_state.lastInputEvent.event_string
Evolution.py:686:                string = orca_state.lastInputEvent.event_string
Evolution.py:1251:        lastKey = orca_state.lastInputEvent.event_string
Evolution.py:1385:            string = orca_state.lastInputEvent.event_string
gcalctool.py:162:            if (orca_state.lastInputEvent.event_string == "space") \
gcalctool.py:163:                   or (orca_state.lastInputEvent.event_string == "Return") \
gcalctool.py:164:                   or (orca_state.lastInputEvent.event_string == "="):
gedit.py:512:           and orca_state.lastInputEvent.event_string == "Return" \
gedit.py:567:           and orca_state.lastInputEvent.event_string == "Return":
gnome-terminal.py:85:            event_string = orca_state.lastInputEvent.event_string
gnome-terminal.py:155:            keyString = orca_state.lastInputEvent.event_string
StarOffice.py:1903:                keyString = orca_state.lastInputEvent.event_string
StarOffice.py:1934:                event_string = orca_state.lastInputEvent.event_string
StarOffice.py:2094:            event_string = orca_state.lastInputEvent.event_string
StarOffice.py:2181:        lastKey = orca_state.lastInputEvent.event_string

I've modified them all to now use
orca_state.lastNonModifierKeyEvent.event_string

(Will/Joanie, please check the one in Gecko.py to make sure it's
the correct change. I don't think you need the
"mods = orca_state.lastInputEvent.modifiers" line immediately
after it either).

So, could people try this patch out please? It's a big change but I
think we need to make it to be more resilient in the case of the how
the user inputs multi-key chords commands.

Patch committed. Putting bug into "[pending]" state.
Please give it a try. Thanks.

Hi Rich, from the testing I've done this seems to be working well.  

Thanks Mike. Closing as FIXED.

Joanie has just found out that the patchlet in comment #13 is
bogus, and is actually preventing selected lines of text being
spoken in OOo Writer. The real fix for this bug was to use the
orca_state.lastNonModifierKeyEvent approach in comment #16.

I've just checked in an unfix to remove the lines of code in 
the patch in comment #13. Things should be working a lot better 
now.

Thanks Joanie!

Reopening. In trying to create a macaroon test for this bug,
I discovered that the problem is currently present.

Created attachment 95871 [details]
Orca debug.out generated whilst testing this.

Steps to reproduce.

1/ Save http://bugzilla.gnome.org/attachment.cgi?id=85811&action=view
   as a file called sample.odt in ~/Desktop
2/ Start OOo Writer
3/ Start Orca
4/ Alt-f to bring up the file menu.
5/ Type "o" to bring up the Open dialog.
6/ Press down arrow to select "sample.odt" and hit Return.

The document will appear in OOo Writer.

7/ Type Control-home to get to the beginning of the document.
8/ Type Control-down to get to the "blank" line between paragraphs.
9/ Type another Control-down to get to the paragraph starting with
   "The saying..."

Listen to the first line of that paragraph being spoken three times.

I did a little more debugging on this.

I was using the OOoWriter sample.odt file at:
http://bugzilla.gnome.org/attachment.cgi?id=85811&action=view

I've noticed that if you have "blank" paragraphs between each one
with real text in it, then Orca will speak the new first line of the
new paragraph three times when you do a Control-down.

If there are no "blank" paragraphs, then Orca will only speak the new 
first line of the new paragraph once, when you do a Control-down.

The difference is in the handling of the "object:text-caret-moved" events
that it receives:

-------------------

Case 1. No blank paragraphs present.

OBJECT EVENT: object:text-caret-moved                  detail=(1,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO'
sayLine: line=<>, len=0, start=0, caret=-1, speakBlankLines=True
sayLine: character=<>, start=0, end=7100432
--- Nothing spoken ------

OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO'
sayLine: line=<>, len=0, start=0, caret=-1, speakBlankLines=True
sayLine: character=<>, start=0, end=7100432
--- Nothing spoken ------

OBJECT EVENT: object:text-caret-moved                  detail=(-1,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO'
sayLine: line=<>, len=0, start=0, caret=-1, speakBlankLines=True
sayLine: character=<>, start=0, end=7100432
--- Nothing spoken ------

OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
sayLine: line=<The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any >, len=104, start=0, caret=0, speakBlankLines=True
SPEECH OUTPUT: 'The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any '

-------------------

Case 2. Blank paragraphs present.

OBJECT EVENT: object:text-caret-moved                  detail=(-1,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
sayLine: line=<>, len=0, start=0, caret=-1, speakBlankLines=True
sayLine: character=<>, start=0, end=7100432
--- Nothing spoken ------

OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
sayLine: line=<The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any >, len=104, start=0, caret=0, speakBlankLines=True
SPEECH OUTPUT: 'The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any '

OBJECT EVENT: object:text-caret-moved                  detail=(-1,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
sayLine: line=<The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any >, len=104, start=0, caret=0, speakBlankLines=True
SPEECH OUTPUT: 'The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any '

OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
sayLine: line=<>, len=0, start=0, caret=-1, speakBlankLines=True
sayLine: character=<>, start=0, end=7100432
--- Nothing spoken ------

OBJECT EVENT: object:text-caret-moved                  detail=(-1,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
sayLine: line=<>, len=0, start=0, caret=-1, speakBlankLines=True
sayLine: character=<>, start=0, end=7100432
--- Nothing spoken ------

OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
    app.name='soffice'            name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'
sayLine: line=<The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any >, len=104, start=0, caret=0, speakBlankLines=True
SPEECH OUTPUT: 'The saying, "Less is more" rings true in the case of exclamation marks! One will suffice for almost any '

-------------------

This seems bogus (YAOOB?). Anybody have any ideas why we'd get six 
"object:text-caret-moved" events for the second case?

> This seems bogus (YAOOB?). 

Agreed.

> Anybody have any ideas why we'd get six 
> "object:text-caret-moved" events for the second case?

So many snarky responses, so little time.... ;-) ;-)

In arrowing about the documents, it seems that when we cross a paragraph boundary we get two events:

  1. detail1 == -1 for the \n (I'm guessing)
  2. detail1 == new caret offset

2 down 4 to go.

Blank lines or not:  It seems that when we press Control Down we get two bogus events.  It's easier to spot if you first move a few characters into the current paragraph before pressing Control Down.  These two are:

  1. detail1 == caretOffset + 1
  2. detail1 == caretOffset

For instance, if we start out with a caretOffset of 10 and press Control Down, we get 4 caret-moved events whose detail1's are 11, 10, -1, and 0 respectively.

I think that's your YAOOB.  Why are we going forward a character and then back a character before crossing into the next paragraph?

4 down 2 to go.

It turns out that you don't need the blank lines to get six events.  Remove your blank lines but position the caret at the end of a paragraph prior to pressing Control Down.  You'll still get six events -- all accounted for by the above:

1. We do our two-step, pre-paragraph-jump warm up:

  a. Going forward a character when we are at the end of the current
     paragraph means we are crossing a paragraph boundary.  And that
     means we get two events: detail1 == -1, detail1 == 0.

  b. Going back a character/returning to our original offset at this
     point means we're once again crossing a paragraph boundary.  And 
     that means we get two events: detail1 == -1, detail1 == <our 
     original offset>

2. Having finished dancing our little jig we're finally ready to move 
   to the next paragraph.  That means, you guessed it, we're crossing
   a paragraph boundary. Therefore we get two events:  detail1 == -1, 
   detail1 == 0.

Voila! 6 events. :-)

Created attachment 95966 [details]
New test case just for this problem.

Thanks Joanie. I'll file YAOOB and block this one against it.

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

>   1. detail1 == -1 for the \n (I'm guessing)

I think this means that the caret is no longer in the paragraph.  So, we might be able to ignore these events.  Rich, can you ask the OOo team what there intended meaning of a detail=-1 on a caret-moved event is?

> For instance, if we start out with a caretOffset of 10 and press Control Down,
> we get 4 caret-moved events whose detail1's are 11, 10, -1, and 0 respectively.

I'm interested in which paragraphs are associated with each event.  I suspect the sequence of detail1={11,10,-1} events are for one paragraph and 0 for another?

Finally, if you set orca.settings.asyncMode=False, it is sometimes easier to view the relative ordering sequence of events.  I'm going to do a little digging to see if we might be able filter things better....

> Rich, can you ask the OOo team what there
> intended meaning of a detail=-1 on a caret-moved event is?

I've added your question as a comment to OOo issue #81824. I suggest
adding yourself to the cc: of that bug to save me having to act as a 
go-between.

Thanks!

> I think this means that the caret is no longer in the paragraph.  

Just based on observation, that would make sense.  The first -1 is for the paragraph that had focus, the second -1 is for the new paragraph (which we leave momentarily in Rich's example), the third -1 is for the paragraph that had focus.
 
> I'm interested in which paragraphs are associated with each event.  I suspect
> the sequence of detail1={11,10,-1} events are for one paragraph and 0 for
> another?

Correct.

OK, for the purposes of digging further, I added the inclusion of repr(self) to the string created by atspi.Accessible.toString.  This outputs the Python object information so we can tell better what object is doing what.  This might be something to just check in since I found it useful to dig with this bug.

When I press Control+Down with the caret on the blank line just after the "Hello. My name..." line I observe the following sequence of AT-SPI events when in synchronous mode: focus/caret go to the next paragraph, but then pop back to the blank line and then pop back to the paragraph.  Strange.  The details are below, and the strange behavior starts with event #6.

I think there are two bugs here -- one in OOo and one in Orca.  The one in OOo is the unexpected jumping of focus.  The one in Orca is that we should filter caret-moved events where detail=-1

0)  Position caret at blank paragraph just after "Hello. My name..." paragraph.

1)  Press Control+Down

2)  object:text-caret-moved                  detail=(-1,0)
    BLANK PARAGRAPH (<orca.atspi.Accessible instance at 0x88903cc>)

  ->VISIBLE:  ' $l', cursor=1
    sayLine: line=<>, len=0, start=-1076518968, caret=-1, speakBlankLines=True
    sayLine: character=<>, start=-1076518984, end=-1220039136

3)  object:state-changed:focused             detail=(0,0)
    BLANK PARAGRAPH (<orca.atspi.Accessible instance at 0x88903cc>)

4)  object:state-changed:focused             detail=(1,0)
    "The saying..." (<orca.atspi.Accessible instance at 0x88903ec>)

5)  object:text-caret-moved                  detail=(0,0)
    "The saying..." (<orca.atspi.Accessible instance at 0x88903ec>)

  ->VISIBLE:  'The saying, "Less is more" rings', cursor=1
    sayLine: line=<The saying, "Less is more" ...>
  ->SPEECH OUTPUT: 'The saying, "Less is more" ...'

ALL GOOD TO HERE!!!!  BUT NOW....

!6)  object:text-caret-moved                  detail=(-1,0)
    "The saying..." (<orca.atspi.Accessible instance at 0x88903ec>)

  ->VISIBLE:  'The saying, "Less is more" rings', cursor=1
    sayLine: line=<>, len=0, start=-1076518968, caret=-1, speakBlankLines=True
    sayLine: character=<>, start=-1076518984, end=-1220039136

!7)  object:state-changed:focused             detail=(0,0)
    "The saying..." (<orca.atspi.Accessible instance at 0x88903ec>)

!8)  object:state-changed:focused             detail=(1,0)
    BLANK PARAGRAPH (<orca.atspi.Accessible instance at 0x88903cc>)

!9)  object:text-caret-moved                  detail=(0,0)
    BLANK PARAGRAPH (<orca.atspi.Accessible instance at 0x88903cc>)

  ->SPEECH OUTPUT: 'blank'
  ->VISIBLE:  ' $l', cursor=1
    sayLine: line=<>, len=0, start=0, caret=0, speakBlankLines=True
    sayLine: character=<>, start=0, end=0

!10) object:text-caret-moved                  detail=(-1,0)
    BLANK PARAGRAPH (<orca.atspi.Accessible instance at 0x88903cc>)

  ->VISIBLE:  ' $l', cursor=1
    sayLine: line=<>, len=0, start=-1076518952, caret=-1, speakBlankLines=True
    sayLine: character=<>, start=-1076518968, end=-1220039136

!11) object:state-changed:focused             detail=(0,0)
    BLANK PARAGRAPH (<orca.atspi.Accessible instance at 0x88903cc>)

!12) object:state-changed:focused             detail=(1,0)
    "The saying..." (<orca.atspi.Accessible instance at 0x88903ec>)

!13) object:text-caret-moved                  detail=(0,0)
    <orca.atspi.Accessible instance at 0x88903ec>

  ->VISIBLE:  'The saying, "Less is more" rings', cursor=1
    sayLine: line=<The saying, "Less is more" ...>
  ->SPEECH OUTPUT: 'The saying, "Less is more" ...'

14) Release the Down key

15) focus:                                   detail=(0,0)
    "The saying..." (<orca.atspi.Accessible instance at 0x88903ec>)

16) Release the Control key

> I think there are two bugs here -- one in OOo and one in Orca.  The one in OOo
> is the unexpected jumping of focus.  The one in Orca is that we should filter
> caret-moved events where detail=-1

Note that the StarOffice.py script does do -1 filtering already for one
specific case. See about line 2273:

            ...
            if (event_string == "Up" or event_string == "Down"):
                if not settings.readTableCellRow:
                    if event.detail1 != -1:
                        self.speakCellName(event.source.parent.name)
                return
            ...

It would be nice if we could make this more generic.

As a possible potential I'm not 100% sure it's the right thing to do workaround, we might try putting a speech.stop() in StarOffice.py:onCaretMoved().

Created attachment 99174 [details] [review]
Revision #1

Nice. This does seem to fix the problem. Thanks!

Yeah!  Thanks!  I say commit this patch, but please add a comment above the speech.stop() line saying why we are doing it and give a reference to this bug report.  There seems to be something odd going on with jumpy focus in OOo and I don't want to lose that.

Created attachment 99220 [details] [review]
Revision #2

This seems to be working better now