Looking at debug.out, it seems we think we're saying it, so I wonder if we're stopping speech to prevent "chattiness" and cutting ourselves off?

vvvvv PROCESS OBJECT EVENT object:text-changed:insert vvvvv
OBJECT EVENT: object:text-changed:insert               detail=(14,1)
---------> QUEUEING EVENT object:text-caret-moved
    app.name='soffice' name='None' role='paragraph' state='editable enabled focusable focused multi line multiselectable showing visible' relations=''
GENERATOR: _getDefaultBrailleRegions
           obj             = Document view
           role            = unknown
GENERATOR: _getDefaultBrailleRegions
           obj             = 
           role            = scroll pane
Object deemed to be for layout purposes only: [panel | ]
GENERATOR: _getDefaultBrailleRegions
           obj             = Untitled1 - OpenOffice.org Writer
           role            = root pane
GENERATOR: _getBrailleRegionsForFrame
           obj             = Untitled1 - OpenOffice.org Writer
           role            = frame
GENERATOR: _getDefaultBrailleRegions
           obj             = Untitled1 - OpenOffice.org Writer
           role            = frame
GENERATOR: _getDefaultBrailleRegions
           obj             = soffice
           role            = application
GENERATOR: _getBrailleRegionsForText
           obj             = 
           role            = paragraph
BRAILLE LINE:  'soffice Application Untitled1 - OpenOffice.org Writer Frame Untitled1 - OpenOffice.org Writer RootPane ScrollPane Document view This is a test. $l'
     VISIBLE:  'This is a test. $l', cursor=16
SPEECH OUTPUT: 'test'
^^^^^ PROCESS OBJECT EVENT object:text-changed:insert ^^^^^

Created attachment 103067 [details]
Orca debug output whilst running this test.

(I started typing "the quick ..." into OOo Writer.)

Yes, that's exactly what's happening.
As part of the "object:text-changed:insert" event (line 700)
we have:

SPEECH OUTPUT: 'the'

queued to be spoken, then when we get a "object:text-caret-moved"
event (line 740), we call speech.stop (line 754 of debug.out and
line 2517 of StarOffice.py).

This was added because of bug #435201. Looks like we are going
to have to add some additional checks before doing the speech.stop().

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

This hopefully fixes the problem (and bug #435201 still
seems fixed as well).

Confirmed.  But I think you want to do a null check on 

   orca_state.lastNonModifierKeyEvent

before you ask for its event_string.  Try launching Orca and then clicking within a paragraph as your first Orca act.  You'll get a traceback and we won't speak the paragraph text.

Also, in testing this I noticed another side effect of bug #435201.  My apologies for not having tested your patch to that bug! :-(  Anyhoo, while independent of this bug I suspect easily fixable as part of your proposed fix.

With or without your patch to this bug, try the following:

1. Take a document with multiple paragraphs separated by blank lines

2. Start from the beginning of a paragraph and press Shift+Down to
   select the text line by line.

We speak each line as we go and that the text is selected, until we select the last line.  That's not spoken.  We just speak the new caret location (in this case "blank").  If I comment out the original speech.stop() we also speak the final selected line.  Given that in this patch you're only stopping speech if the event_string is "Up" or "Down", could you also do a check to see if it's not modified by Shift?  Just a thought....

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

Patch adjusted based on Joanie's feedback. It still sometimes says
"bl bl blank" when you Control-[Up, Down] to a blank line, but we 
are getting multiple events and we are stopping the speech each time.
this is really YAOOoB that we are trying to work around.

This works for me on all fronts.  I am not seeing the bl bl blank either.  Thanks Rich!

Thanks. Patch committed. Moving to "[pending]".

This seems to work well for me.  thanks much 

Thanks. Closing as FIXED.