Skip to content

When "Braille tethered to" option is set to review, it's not possible to move the caret when you press routing buttons on braille display #3166

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.

Sign up for GitHub

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
Closed
nvaccessAuto opened this issue Apr 17, 2013 · 14 comments · Fixed by #15064
Closed

When "Braille tethered to" option is set to review, it's not possible to move the caret when you press routing buttons on braille display #3166

nvaccessAuto opened this issue Apr 17, 2013 · 14 comments · Fixed by #15064
Labels
component/braille enhancement
Milestone
2023.2

Comments

@nvaccessAuto
Copy link

Reported by sergioneves on 2013-04-17 15:15
I'm using NVDA (last development version) and Focus 40 braille display.
Steps to reproduce:

  1. Go to NVDA menu -> Preferences -> Braille settings.
  2. Access the combo box labelled "Braille tethered to", change the selected option to "review" and press ok to save.
  3. Open a text editor, like notepad.
  4. Write some text and try to press the routing buttons on the braille display, in order to move the caret to the character you want.
    Expected result: both the caret and the braille cursor move to the character you want.
    Actual result: only the braille cursor moves to the character; the caret remains in the position it was before.

Note that when the option "Braille tethered to" is set to focus, the problem doesn't happen.
I think it's important to have the content of the braille display updated as you move the flat review cursor, without losing the possibility of using the routing buttons to change the caret position.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2013-04-17 19:55
When tethered to review, any movement moves the review cursor. Otherwise, it wouldn't be possible to see the review cursor or move it somewhere without affecting the caret. I'm not really sure how this could be done without losing these abilities.

If you mean flat screen review (and not just reviewing an object), it's not possible to reliably move the caret in flat review anyway.

@nvaccessAuto
Copy link
Author

Comment 2 by ragb (in reply to comment 1) on 2013-04-17 23:08
Replying to jteh:

When tethered to review, any movement moves the review cursor. Otherwise, it wouldn't be possible to see the review cursor or move it somewhere without affecting the caret. I'm not really sure how this could be done without losing these abilities.

I believe Sérgio's problem is a bit different. It is in the way routing buttons are handled. He was expecting that when pressing a routing button the caret would move to the character undernith the routing button, in a text box. This behavior happens when braille is fixed to Focus, but not when fixed to review cursor. More strangely, when braille is fixed to review cursor and you press a routing button on a text edit, the braille cursor blinks as it should when the caret is moved, but the actual caret position is kept unchanged (move arrows or something to verify).

This is not that clear, but the fact is that it isn't easy to explain.

P.S. Sérgio (the reporter) is my co-worker so I have access to the source :).

Regards,

Rui Batista

@nvaccessAuto
Copy link
Author

Comment 3 by jteh (in reply to comment 2) on 2013-04-18 01:03
Replying to ragb:

I believe Sérgio's problem is a bit different. It is in the way routing buttons are handled.

Routing buttons count as movement. When you route, ti just moves the cursor to a specific spot, depending on what you're tethered to.

More strangely, when braille is fixed to review cursor and you press a routing button on a text edit, the braille cursor blinks as it should when the caret is moved, but the actual caret position is kept unchanged (move arrows or something to verify).

That's because when tethered to review, the braille display shows the review cursor, not the caret. See my initial comment for the reasons.

@nvaccessAuto
Copy link
Author

Comment 4 by sergioneves (in reply to comment 3) on 2013-04-18 06:13
Replying to jteh:

Replying to ragb:

I believe Sérgio's problem is a bit different. It is in the way routing buttons are handled.

Routing buttons count as movement. When you route, ti just moves the cursor to a specific spot, depending on what you're tethered to.

More strangely, when braille is fixed to review cursor and you press a routing button on a text edit, the braille cursor blinks as it should when the caret is moved, but the actual caret position is kept unchanged (move arrows or something to verify).

That's because when tethered to review, the braille display shows the review cursor, not the caret. See my initial comment for the reasons.

Is it possible to implement the following in order to workaround this limitation? (I don't have much knowledge about the internals, so probably you have to adapt my suggestion).
When we press a routing button, NVDA checks if the braille cursor is in a textbox control (at least the most common text box controls you know) and if the braille is tethered to review.
If the two checks yield true,

  1. NVDA moves the review (braille) cursor to the character, like it does now, but saves the location where we press the routing button (textbox index);
  2. tethers braille temporarily to focus;
  3. Performs the same action that it would perform if the option is set permanently to tether focus (it moves the caret to the character we wish, that is, moves the caret to the review cursor);
  4. Tethers the braille to review again.
    Or, another alternative... Is it possible to check if the review mode is enabled (through keys user presses) and, according to this, change where braille tethers to?
    I don't know the complexity involved in this implementation, but I think it's very important that this situation is solved in the future (medium/long term).
    Ideally, I think the responsability of setting where braille tethers to is at NVDA side, not at user side.
    If I assume the user role, I would say that in the majority of scenarios, when he is in a text box and he presses a routing button,
    it's because he wants to edit the content at this position, and not because he wants to review the object. On the other hand, when reviewing an object, he probably wants to review it with braille too, like it do now when braille tethers to review.
    Thanks for your attention and your extraordinary work.

@nvaccessAuto
Copy link
Author

Comment 5 by jteh on 2013-04-18 06:18
See also #2385.

@nvaccessAuto
Copy link
Author

Comment 6 by ragb on 2013-04-18 09:01
Hi,

Seeing this comments and the ones in #2385 I'm tempted to say that users are expecting braille routing buttons to activate the "clicked" item (the item wich text was cclicked) and not specifically moving the review cursor, even if braille is fixed to review. In text boxes, as far as I know, activating a character is the same as moving the caret there.

Does that make sense?

@nvaccessAuto
Copy link
Author

Comment 7 by jteh (in reply to comment 6) on 2013-04-21 01:25
Replying to ragb:

Seeing this comments and the ones in #2385 I'm tempted to say that users are expecting braille routing buttons to activate the "clicked" item (the item wich text was cclicked) and not specifically moving the review cursor, even if braille is fixed to review.

Yes, I know what they're expecting. However, this makes it impossible to see or move the review cursor for a braille only user, which is bad because it doesn't allow you to, for example, query the formatting of a given character or copy to the clipboard using the review cursor.

@nvaccessAuto
Copy link
Author

Comment 8 by heikofolkerts on 2013-07-11 18:02
I understand both parties here. When the braille display is set to review mode the routing just moves the review cursor. But nomally users want to edit text, click things when routing on their braile display. If I had known about that little difference in NVDA I could have saved quiet a bit of time and hadn't turned on my other screen reader just to correct some text.

Sop my proposal is just to document the fact that changing the linkage of the braille display to review will change the routing behaviour. Since most braille displays have a button to change the linkage setting switching it will be no real problem for users. So with the feature documented every body can get what he wants.

Beside this comment this is another reason why nvda should use application specific settings - so a text editor would set the braille linkage once and the user can make its routing.

@heikofolkerts
Copy link
Contributor

After reading all this comments and that of the referenced ticket I think the key points are in #6 and #7. Ofcourse we shouldn't risk blocking braille only users so using routing keys should be switchable from just moving the review cursor or moving it and performing a click on that position afterwards. I mean a click with the mouse since this way the routing keys can be used for moving just the review dursor as stated in #7, place the caret to edit text (which is the most used situation) and just click a button or whatever to activate controls etc. Even if this kind of click is hard in screen review mode it would be helpful in object navigation alone.

So what I request ist just

  • create an option (with a hotkey if possible) to decide whether the routing key should trigger the mouse to be moved to the new position of the review cursor and perform a click or just behave as in the current version.
  • enhance the responsible script that handles the movement of the review cursor to move and click the mouse.

I think this little confusion or specific behaviour makes it quite strange and hard for beginners and it is error prone to advanced ones because one forgets to switch cursors and realizes it when wrong edits are made.

@jcsteh jcsteh mentioned this issue Jun 5, 2017
Closed
@Adriani90
Copy link
Collaborator

@LeonarddeR, @michaelDCurran unfortunately I do not have a braille display to test this but I guess this is still an issue even with automatic tetering. Right?

@Adriani90
Copy link
Collaborator

@jcsteh I guess the discussion was not been further expanded an NV Access. Right?
@sergioneves please test it if possible with automatic tetering and tell us if this issue still occurs.

@jcsteh
Copy link
Contributor

jcsteh commented Dec 11, 2018

I can't comment with certainty as to NV Access's plans or opinions concerning development, since I'm not a developer there any more. :) As far as I know, there hasn't been any further discussion on this.

@LeonarddeR
Copy link
Collaborator

I'm also not able to speak on behalf of NV Access, but personally I believe that this is not a bug. @jcsteh has explained this in #3166 (comment) . I would say that especially now auto tethering is there, the only thing we can consider is changing the action of the routing buttons when tethering is set to auto, while it it is temporarily tethered to review (e.g. because of a review move). However, when braille is tethered to review explicitly, behaviour should stay as is.

@Adriani90
Copy link
Collaborator

@LeonarddeR this sounds reasonable. I think if system carret follows review cursor in edit fields, then it should work properly. As of now, review cursor follows system carret but not vice versa. This could be an optional setting in braille settings because for speech this is not very important I guess.

@burmancomp burmancomp mentioned this issue May 25, 2023
Closed
@LeonarddeR LeonarddeR mentioned this issue Jun 28, 2023
Merged
6 tasks
seanbudd pushed a commit that referenced this issue Jul 11, 2023
@LeonarddeR
Move the system caret when routing review cursor (#15064)
c6bdc66 
Fixes #14885
Fixes #3166

Summary of the issue:
It has not been possible to move system focus/caret with single routing button press when braille is tethered to review, or when braille is tethered to automatically and follows temporarily review cursor. When user wants to review editable text without affecting system caret position (braille tethered to review continuously or temporarily), it maybe useful if he/she can route caret when needed for example to correct typos. Although thiskinds of routing has been possible, it has required at least one extra routing button press.

Description of user facing changes
A new setting Move system caret when Routing review cursor is added:

Never (Default): No change
Only when tethered automatically: Routing keys will move the caret or focus when tethered automatically. When explicitly tethered to review, routing keys won't move the caret
Always: Regardless whether tethered to review or automatically, routing the review cursor will move the caret or focus
Description of development approach
This pr takes a different approach to #15044.

The logic is not in the routing scripts in globalCommands but instead on the braille.ReviewTextInfoRegion class as well as two new region types for review cursor and objects. First of all, TextInfoRegion.routeTo has been split into two methods. This ensures that we can override the routing behavior for the review cursor regions without touching the BrailleInput logic. Furthermore, the following changes were added/changed:

ReviewNVDAObjectRegion: simply sets focus to the object before executing the default action
ReviewCursorManagerRegion. Inherrits from ReviewTextInfoRegion and CursorManagerRegion to ensure that ReviewTextInfoRegion._routeToTextInfo calls the right super class on cursor managers
ReviewTextInfoRegion: implemented _routeToTextInfo to support the new behavior. It always calls the super class to execute the normal routing action (i.e. moving the review cursor and activating the position). When routing should move the system caret, it calls setFocus on an object when the underlying TextInfo class is DisplayModel, i.e. when in screen review. Otherwise, it calls setCursor on the super class, which translates to moving the system or cursor manager caret.
@nvaccessAuto nvaccessAuto added this to the 2023.2 milestone Jul 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component/braille enhancement
Projects
None yet
Milestone
2023.2
Development

Successfully merging a pull request may close this issue.

Move the system caret when routing review cursor LeonarddeR/nvda
6 participants
@LeonarddeR @jcsteh @nvaccessAuto @heikofolkerts @ehollig @Adriani90