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

Fix Edit.makeTextInfo(caret) when selection is present #16455

Open
wants to merge 1 commit into
base: beta
Choose a base branch
from

Conversation

mltony
Copy link
Contributor

@mltony mltony commented Apr 26, 2024

Link to issue number:

N/A - please let me know if you want me to create a proper issue first

Summary of the issue:

Suppose some text is selected in NVDA log viewer. Caret can be either at the beginning or at the end of selection, depending on whether we selected text back or forward. Now when calling

focus.makeTextInfo('caret')

I observed that instead of actual caret position, it always returns the beginning of the selection, which is wrong.

Description of user facing changes

N/A as far as I can tell.

Description of development approach

This PR fixes bug in NVDAObjects.window.edit.ITextDocumentTextInfo class.
I query ITextSelection.Flags and check whetehr tomSelStartActive flag is set, and depending on that I collapse either to beginning or to the end depending where the curosr actually is located at the moment.

Testing strategy:

Tested manually in NVDA log viewer. In order to figure out where caret resides I use the following snippet:

t=focus.makeTextInfo('caret')
t.move('character', 1, 'end')
t.text

Known issues with pull request:

N/A

Notes

Just for the record if anyone is interested why I'm proposing this change. I am working on customized word selection script for WordNav add-on and one thing I need is to be able to determine whether caret is currently residing at the beginning or at the end of the selection. It would help if this issue is fixed in the core.

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.

@mltony mltony marked this pull request as ready for review April 26, 2024 23:51
@mltony mltony requested a review from a team as a code owner April 26, 2024 23:51
Copy link
Collaborator

@LeonarddeR LeonarddeR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

gerald-hartig
gerald-hartig previously approved these changes Apr 29, 2024
@seanbudd seanbudd added the conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. label Apr 30, 2024
@seanbudd seanbudd added this to the 2024.2 milestone May 1, 2024
seanbudd
seanbudd previously approved these changes May 1, 2024
@seanbudd seanbudd changed the base branch from master to beta May 8, 2024 03:26
@seanbudd seanbudd dismissed stale reviews from gerald-hartig and themself May 8, 2024 03:26

The base branch was changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. queued for merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants