Created attachment 79784 [details]
Sample text file to use to reproduce the problem.

The problem can be reproduced with a simple two line file:

Line 1
Line 2

Make sure that there is a Return character on the end of each line.
Position the text caret at the beginning of the first line then
arrow Down and Down again. "Line 2" will be spoken twice.

The problem is in util.getTextLineAtCaret(). There is a piece of
code in there that goes:

    if text.caretOffset == text.characterCount:
        caretOffset = max(0, text.caretOffset - 1)
    else:
        caretOffset = text.caretOffset

For the first line we get:

getTextAtLineCaret: text.caretOffset: 0
getTextAtLineCaret: text.characterCount: 14
getTextAtLineCaret: caretOffset:  0

For the second line we get:

getTextAtLineCaret: text.caretOffset: 7
getTextAtLineCaret: text.characterCount: 14
getTextAtLineCaret: caretOffset:  7

When the caret is below that second line we get:

getTextAtLineCaret: text.caretOffset: 14
getTextAtLineCaret: text.characterCount: 14
getTextAtLineCaret: caretOffset:  13

If I replace it with

        caretOffset = text.caretOffset

everything seems to work fine. 

The change went in with revision 1.54 to util.py on 15th December 2006
The ChangeLog entry is:

        * src/orca/util.py: in getTextLineAtCaret, handle case where the
        caret is at the very end of the last line of the text.

I repeated the tests above with the caret at the end of each line
and it still seems to work fine.

Will, what am I missing?

After some digging, the util.py change from 15-Dec was to handle the editable entry areas of autocomplete fields in Firefox.  The "Location" and "Search" fields are such beasts.  Without this change, braille doesn't display anything for the contents of the entry.  With this change, braille shows the contents.

I believe the offset passed into the getTextAtOffset method is intended be an offset of a character in the text.  If that is true, then passing in an offset outside this range (text.characterCount is outside this range) is not valid and the behavior and return results of the method are undefined.  Note that my expectation is that offset should be allowed to be text.characterCount and getTextAtOffset should do the right thing.  I'll dig some more, but I believe I've had this battle with implementors of at least one AT-SPI implementation beside that in GTK+ and I've lost. 

Given this, I think the one edge case we need to account for is if the caret offset is beyond the last character and the last character is a newline.  In these cases, we can omit the call to getTextAtOffset since we already know we're on an empty line.  I'll work up a patch.

Created attachment 80027 [details] [review]
Patch to accommodate Gecko and GTK+ behavior

Committed patch and closing as a result.  Tested with Firefox 3.0a2, GEdit, and OOo.