caret and review position with selection
Opened this issue · 12 comments
Steps to reproduce:
case 1
- open for example bug report template as if you were about to report bug
- try with firefox (maybe other browsers apply) to select text with shift+down arrow when you are in focus mode
- inspect caret and review position during selection
case 2
- open wordpad (in windows 10)
- type some lines text
- go to start of file and select text with shift+down arrow
- inspect caret and review position during selection
- do same with notepad and word (I have 2019).
Actual behavior:
In firefox and in wordpad review position is different from other cases - it is start of first unselected line. Other cases it is start of selection. Tests done when review follows caret.
As to wordpad #16455 seems to be something to do with this which I describe here. As to firefox I do not know.
Expected behavior:
same behavior in all cases
NVDA logs, crash dumps and other attachments:
System configuration
NVDA installed/portable/running from source:
mainly tested runnin from source
NVDA version:
from current main branch
Windows version:
windows 10 22h2
Name and version of other software in use when reproducing the issue:
firefox 125.0.3
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Have you tried any other versions of NVDA? If so, please report their behaviors.
behavior with 2024.1 in firefox might be same as described here
If NVDA add-ons are disabled, is your problem still occurring?
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Does this negatively affect the user? How so? This just seems like a description of known different behaviour depending on the application
When considering "show selection when braille is tethered to review" I think that different behavior in different applications would not at least facilitate implementation. I think that there should be reason if behavior varies between applications/situations.
I think that suitable solution in general could be that review position would be in end of selection in all situations if review follows caret (and then if braille follows review).
Now as to this issue review position is - at leas when selecting with shift+down arrow - in next line after selection. In many (likely in most) cases it is in start of selection.
So for consistency I think that behavior should be same in all situations if there is no special reason/situation for different behavior.
cc: @jcsteh maybe you can give some insights why the position of review is different when selecting text in different applications. My understanding is also that the position of the review cursor should always be at the end of selection, in line with system caret or maybe also in line with virtual cursor in browse mode.
In Firefox, the review cursor reflects where the caret actually is. If you're selecting forward, the caret will be at the end of the selection. If you're selecting backward, the caret will be at the start. If the review cursor is following the caret, it will be likewise positioned.
Wordpad (and other things using the same control) were fixed to behave this way in #16455. IMO, this is the correct behaviour.
As for why other controls behave differently, those APIs don't give us a way to tell which end of the selection is the active end; i.e. which direction we're selecting in.
In my system (windows 10 2022h2) in wordpad it goes so that if I have following text (without quotes):
"line 1
line 2
line 3
"
And I go to start of text with control+home, and then press shift+down arrow, review position is upon letter l of line 2.
Same happpens with firefox (I just tested during writing of this comment).
So when selecting text as described above, review position goes outside of selection.
In notepad review position remains in start of first line. I suppose it means that same fix is not yet implemented for it.
When review follows caret, it sounds good that review position is in active end of selection. But as said, it does not work in wordpad for me nor in firefox.
So when selecting text as described above, review position goes outside of selection.
The caret is at the start of the next line, just after the end of the selection, waiting for you to potentially select more text. When I said end of the selection, I probably should have said "just after the end of the selection".
In notepad review position remains in start of first line. I suppose it means that same fix is not implemented for it.
Unfortunately, I don't think we can implement a fix for that. As I noted above, the APIs we use to get information from those controls don't provide a way for us to know where the active end of the selection is.
So when selecting text as described above, review position goes outside of selection.
The caret is at the start of the next line, just after the end of the selection, waiting for you to potentially select more text. When I said end of the selection, I probably should have said "just after the end of the selection".
With braille I regard this as problem. Considering situation braille is tethered to review and selecting text.
Of course it can be said that in many cases braille shows first line of selection in that case so why this is problem then?
I think that showing selection or not in braille (with dots 7 and 8 for example) if you want that braille is tethered review (and review follows caret) behavior should be similar to situation where braille is tethered to focus. I mean when braille is tethered to focus and text is selected braille shows last line of selected text (when selecting shift+down arrow). Same logic should be applied to braille when tethered to review.
If caret is in start of next line and review is also there why braille when it is tethered to focus shows last line of selected text? It is good that it shows it. So it should do same when it is tethered to review. If exception (cursor is just after selection but last selected line is shown) is acceptable when braille is tethered to focus what is reason that it is unacceptable when braille is tethered to review? I think that when braille is tethered to review there are new possibilities with braille.
So same behavior - no matter which braille is tethered to would sound good at this moment.
That's reasonable. Note that I was specifically asked in #16549 (comment) why the behaviour is different and I'm explaining that difference, as well as why the caret position is correct for Firefox and Wordpad. I didn't intend to answer any other question here.
The fact that this has a negative impact on braille tethered to review is a fair point, but altering the reported caret position is not the correct fix. The correct fix would be somehow teaching braille review tethering to honour selection instead of caret.
Is correct approach to close this issue and open new issue referring to braille or modify this issue (title and issue description) (because matter has been discussed here)?
I think this issue is fine as is. I was just clarifying where the fix needs to be to ensure there is a clear idea of the correct path forward here so time isn't wasted working on an incorrect solution. Thanks!
If review follows caret, and braille is tethered to review, then when selecting text braille should display what you selected (end of selection), and not what you would select next (text just after selection). I think it is better to try to adjust review position so that braille displays end of selection every time when selection changes because for example in wordpad review position changes anyway when selecting text. According to my understanding "old style" where review position remains in beginning of selection is not adequate anymore.
If there is selection and user press "move to focus" then braille can jump to caret which may mean displaying content just after selection or start of selection.
Pr #16468 tries to solve this issue. It demonstrates selecting text when braille is tethered to review. It can be tested both "show selection" enabled and disabled.