Using up and down arrows at the end of narrow columns can result in lines being skipped

[Qchristensen]

I initially encountered this editing a cell with wordwrap in Excel, but can also replicate in Notepad and WordPad (not Word). The exact settings may depend on factors such as screen DPI, but on my system:

In all three programs, open a blank file and type the text: The quick brown fox jumps over the lazy dog.

Then:

In Excel, turn Wordwrap on by pressing alt+h then w, and edit the cell with F2.

In WordPad, press the applications key, then select "Paragraph" and in the dialog box, set both the left and right indentation to 6cm.

In NotePad, the window itself needs to be narrowed. Press alt+spacebar to open the system menu, press S for size, press the right arrow to move the focus to the right edge of the window, then hold down the left arrow for about five seconds to make the window as narrow as possible.

Each line contains one or more words, then a space (no space after the very end of the text).

Press the up and down arrow keys to move through the lines. Find what is likely to be the longest line and press end to move to the right edge of that line, then repeat moving up and down. When the focus moves to a line that is shorter than the current line, the caret moves to the position to the right of the space at the end of the line and NVDA reads the NEXT line.

If the caret is earlier in the line or at the start of the line, navigation moves through the text as expected.

For instance, in Excel, for me, my cell has the text:

The quick
brown fox
jumps
over the
lazy dog.

Each line has two words except "jumps". Having moved the focus to the very end of the text, NVDA reads "lazy dog." Press up arrow and the focux moves to the end of the previous line and NVDA again reads "lazy dog.". Press up arrow again and the focus moves to the end of jumps but NVDA reads "over the ". Once more and the caret moves partway through the brown fox line and so reads "brown fox".

(Edit: As per conversation, this issue also affects text in browsers, and likely most programs. I have closed #8925 on that basis. The suggestion to replicate in a browser there was to open a new issue on our issue tracker here, and in the body put a long line of text such as: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbb ccccccccccccccccccccccccccccccccccccccccccccccccccccccccc (remove extra line breaks inserted by GitHub if you copy it from here), and then move to the end of the line and navigate between lines, - basically the same way to replicate it as in Wordpad etc.)

[jcsteh]

The technical reason this happens is that the caret moves to the right of the last character on the line, but this position is not represented by a character and thus has no "offset". (We use offsets to access text in these controls.) Thus, the caret offset returned by the application is just the offset for the next character. The API does not indicate that this is the end of the line, not the start of the next.

This also happens in Firefox, but IA2 at least provides a way for us to fix this (albeit one we haven't implemented yet). See #3156.

One possibility is that when fetching the caret, we might be able to get the screen coordinates of the caret (using the caret rect from GUIThreadInfo) and compare this to the screen coordinates of the character. If they are significantly different, we know the caret is actually at the end of the line.

P3 because while this is definitely problematic, it doesn't occur that often and investigating/implementing a fix is likely to be rather time consuming.

[Adriani90]

cc: @LeonarddeR

[Adriani90]

@Qchristensen is this maybe the same like described in #8925? That one focuses on browsers but I tend to think this is indeed a behavior which can be seen system wide.
If it is the same issue, then I suggest to close #8925 in favor of this one and to adjust the description to include browsers as well.
Thanks.

[Qchristensen]

Trying the suggestion in #8925 (copying that long string of letters into the new issue template) does seem to result in the same behaviour yes, so it likely is the same cause. I will close that issue and expand the description of this issue.