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

With each of the "object:text-caret-moved" events, we are calling the
onCaretMoved() method in StarOffice.py.

Inside that routine there is some code that Lynn wrote that does:

        # Speak a newline, if appropriate.
        if self.speakNewLine(event.source):
            speech.speak(chnames.getCharacterName("\n"), None, False)

With the last "object:text-caret-moved" event (line 1557), we are
returning True when calling speakNewLine().

Specifically it's returning true because of:

        if isControlKey:  # control-right-arrow or control-left-arrow

            # Get the word containing the caret.
            word = text.getTextAtOffset(caretOffset, \
                pyatspi.TEXT_BOUNDARY_WORD_START)
            wordStart = word[1]
            wordEnd = word[2]

            if lastKey == "Right":
                if wordStart == lineStart:
                    return True

and it then speaks "newline".

Currently, I've no idea how to fix this. Suggestions welcome.

Aha!  Finally, something good comes from eating and breathing and dreaming getTextAtOffset() and TEXT_BOUNDARY_FOO! ;-)

When one selects text to the right, the caret is just after the selection -- in this case, just before the period (or were it not there, the newline).  At that point, when you ask for the word at offset, you don't have a word at that offset.  Therefore, you expect one of two things (at least based on my FF experience):

1. An empty word: ('', 0, 0)
2. A bogus word:  ('', -12345678, -987654321)

(You can't predict the latter bogus numbers afaik, but they're usually quite large and negative).  Regardless of the flavor, if your word[0] is an empty string this bit:

>             if lastKey == "Right":
>                 if wordStart == lineStart:
>                     return True

shouldn't automatically be returning True.  Were it me, I'd probably add an additional check for an empty string in word[0] and see what if anything breaks as a result. :-)

Created attachment 105252 [details] [review]
Attempt at solution suggested by Joanie in last comment.

Thanks for the suggestion Joanie. It's either not working,
or I'm not correctly understanding what you suggest because
it's not fully working. Admittedly it now stops speaking
"newline" at the test case reported in the bug description,
but it's no longer speaking "newline' at the end of the line.

Also note that "going the other way" (Control-Shift-Left from
the end of the line), is resulting in the speaking of a bogus
"newline" and checking for word[0] being "" isn't going to help 
here.

I'll IM you to see if we can make further progress on this one.

> it's not fully working. Admittedly it now stops speaking
> "newline" at the test case reported in the bug description,
> but it's no longer speaking "newline' at the end of the line.

Was it speaking it before?  See bug 387556.  It seems that in OOo Writer, we say nothing about newlines until we've already gone past them.  

When I try the first part of your patch:

             if lastKey == "Right":
-                if wordStart == lineStart:
+                if word[0] and wordStart == lineStart:
                     return True

And use the expanded test case:

  The quick brown fox
  jumped over the lazy dog

(indentation not in the actual document; just here)

If I move word by word to the right with Control + Right, we still speak "newline jumped" just as we did without your change.  If I select word by word to the right, we no longer speak the newline when selecting fox.

(As an aside, if you keep selecting, we say other stuff we shouldn't be saying, but that occurs with or without your patch).

> Also note that "going the other way" (Control-Shift-Left from
> the end of the line), is resulting in the speaking of a bogus
> "newline" and checking for word[0] being "" isn't going to help 
> here.

Yup.  If we treated the EOL as the newline this would be easier. ;-)  I'll give the "other way" case some more thought.

> I'll IM you to see if we can make further progress on this one.

Okie dokie. 

> Was it speaking it before? 

Apparently not. 

I also noticed that completely independent of the patch and this bug, if you have the text:

The quick brown fox
jumped over the lazy dog

And move the caret to the 'j' of jumped and then press left arrow once, we say "newline newline".

Put another way, I'm wondering if now would be a good time to look at bug 387556.  If we speak the newline char when we're actually on the newline char I think things will largely work themselves out (or be simpler to work out).  And, as an aside, saying something at that character (as opposed to nothing) would provide users with an experience which is more consistent with other screen readers.  At least that's my 2 cents worth....

Marking this one as a dup of bug 517048 because it turns out that this bug is merely one manifestation of a much more significant problem, outlined in the newer bug.

*** This bug has been marked as a duplicate of 517048 ***