Using up and down arrows at the end of narrow columns can result in lines being skipped #7078
Labels
p4
https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
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.)
The text was updated successfully, but these errors were encountered: