Braille: show selection when tethered to review in edit controls and documents

[burmancomp]

Link to issue number:

closes #3095, #15994, #16549

Summary of the issue:

When braille is tethered to review selection is not shown in edit controls and documents.

Description of user facing changes

Selection is shown when "Show selection" setting is enabled.

Description of development approach

Variant of #16038 which does not depend on scripts.

Testing strategy:

Known issues with pull request:

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[burmancomp]

I wanted to try second time. This version does not depend on scripts.

@LeonarddeR what do you think, is this ready for close?

[burmancomp]

Could you @Jykke67 / @irrah68 / @Emil-18 test this build https://ci.appveyor.com/api/buildjobs/wi5nx56hfrfrwehe/artifacts/output%2Fnvda_snapshot_pr16468-32166%2Cff82fa3e.exe.

Behavior has changed when show selection is disabled; also hopefully a couple of fixes from previous build of this pr.

See also discussion in issue #16549.

[irrah68]

I tested this pr but I didn't notice any strange things. My Braille display showed the last line of the selected area as selected.

But I found an interesting thing when I tested with Notepad (Windows 11). When I selected a text area with Shift+DownArrow very slowly, the Braille display was showing the first line of — for example — three selected lines. But when I selected the same lines very fast or in a so called normal way, the display was showing the last selected line. I couldn't reproduce this in Wordpad, only in Notepad.

Braille is tethered to review and review follows caret.

[LeonarddeR]

@burmancomp I'm very sorry for the inconvenience, but I'm going to close this pull request for now. As clearly stated by @seanbudd in #16038 (comment), #12772 needs to be addressed first. Also @michaelDCurran stated in #16038 (comment) that he has his concerns about the proposed behavior.
I think I speak for everyone when I say that your efforts are greatly appreciated. However, you also honestly indicate that your skills are limited. We are talking about a part of the braille code where in-depth knowledge of the braille module is really necessary.
So if you really want to take a step forward with this, I'd suggest investing your time into fixing #12772, that is if @seanbudd is not planning to do this himself.

[burmancomp]

May I ask what were problems in implementation this time?

[Jykke67]

I don’t have any answer to you, but I doubt if my testing of the latest PR would give more information of interest. Of courese I can still test it, even though the issue is already closed.

[Jykke67]

Updated to this PR but found no difference to the previous ones.

Talking about NVDA pr16468-32166,ff82fa3e.