Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

review position isn't updated when moving through edit field with shift key pressed #250

Open
nvaccessAuto opened this issue Jan 1, 2010 · 7 comments
Open

review position isn't updated when moving through edit field with shift key pressed #250

nvaccessAuto opened this issue Jan 1, 2010 · 7 comments
Labels
bug p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority

Comments

@nvaccessAuto
Copy link

nvaccessAuto commented Jan 1, 2010 •
edited by feerrenrut

Reported by aleksey_s on 2008-12-04 21:45

when you select text in edit field and press insert+uparrow or numpad8, nvda reports current line as it is first before selection.

steps to reproduce

  • start notepad
  • enter two lines of text: "Hello" and "World"
  • go to start of document
  • press shift+down arrow
  • press numpad8

Actual result

nvda announces the first line of text: "Hello"

expected results

nvda must announce second line of text, which is really current line: "World"
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2008-12-04 22:15
The review cursor should definitely move. However, we actually have no idea where the caret is, as the caret and the selection are one and the same. Thus, we have to decide: should the review cursor always move to the start of the selection or the end? Moving to the start is normally what would be expected, but if you are selecting backwards, this is not ideal. Our selection code might be aware of which direction we're moving in, so maybe we can use that to make this determination. Mick, any thoughts?

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2009-06-23 05:57
Changes:
Milestone changed from 0.6 to None

@jcsteh jcsteh mentioned this issue Feb 23, 2016
Closed
@LeonarddeR
Copy link
Collaborator

@dkager, Is this somehow covered in #6775? Probably not

@dkager
Copy link
Collaborator

dkager commented Jun 8, 2017

No, but that could could be a good starting point. It would add an attribute indicating at which end the selection is anchored.

@feerrenrut
Copy link
Contributor

I have updated the description to make this a little easier to talk about.
I can reproduce this in NVDA next-14098,66f26bb2.
Visually I can confirm that when positioning the caret before the 'H' pressing shift down results in the caret moving to the second line, before the 'W' character.
After removing the selection and positioning the caret before the 'W' pressing shift up results in the caret moving to the first line, before the 'H'.

@feerrenrut feerrenrut added the p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Jun 12, 2017
@feerrenrut
Copy link
Contributor

Setting this as priority 2 since it seems related to some recent work in #7131 (Though I'm not suggesting this is a regression caused by it)

@Adriani90
Copy link
Collaborator

cc: @JulienCochuyt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug p3 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@LeonarddeR @dkager @feerrenrut @michaelDCurran @nvaccessAuto @Adriani90