Incorrect behaviour of UIA IUIAutomationTextRange::Select #11050

Closed
opened 2026-01-31 02:37:12 +00:00 by claunia · 2 comments
Owner

Originally created by @codeofdusk on GitHub (Oct 16, 2020).

From the docs:

If the Select method is called on a text range object that represents a degenerate (empty) text range, the text insertion point moves to the starting endpoint of the text range.

Most Braille displays have cursor routing keys above each cell for efficiently moving the caret. NVDA relies on this behaviour of the select method on UTRs to allow Braille users to navigate.

Cc @carlos-zamora, @mehgcap.

Originally created by @codeofdusk on GitHub (Oct 16, 2020). From [the docs](https://docs.microsoft.com/en-us/windows/win32/api/uiautomationclient/nf-uiautomationclient-iuiautomationtextrange-select): > If the Select method is called on a text range object that represents a degenerate (empty) text range, the text insertion point moves to the starting endpoint of the text range. Most [Braille displays](https://en.wikipedia.org/wiki/Refreshable_braille_display) have cursor routing keys above each cell for efficiently moving the caret. NVDA relies on this behaviour of the `select` method on UTRs to allow Braille users to navigate. Cc @carlos-zamora, @mehgcap.
claunia added the Product-ConhostResolution-By-DesignIssue-BugArea-Accessibility labels 2026-01-31 02:37:12 +00:00
Author
Owner

@carlos-zamora commented on GitHub (Oct 16, 2020):

Hmm... This is interesting. This seems to be another problem with comparing how text editors work vs how a terminal works. When a degenerate range is selected on a text editor, the insertion point (cursor) is the position of the degenerate range. But on a terminal, the insertion point is always the prompt at the bottom.

I don't think we can change the behavior of GetSelection() because this is the only way to get the cursor position. But on the other hand, Braille clearly relies on this because they're making degenerate selections. Would it be possible for Braille to expand by character to properly highlight the word letter you're on?

@carlos-zamora commented on GitHub (Oct 16, 2020): Hmm... This is interesting. This seems to be another problem with comparing how text editors work vs how a terminal works. When a degenerate range is selected on a text editor, the insertion point (cursor) is the position of the degenerate range. But on a terminal, the insertion point is always the prompt at the bottom. I don't think we can change the behavior of `GetSelection()` because this is the only way to get the cursor position. But on the other hand, Braille clearly relies on this because they're making degenerate selections. Would it be possible for Braille to expand by character to properly highlight the word letter you're on?
Author
Owner

@carlos-zamora commented on GitHub (Oct 16, 2020):

Discussed offline. The issue described is by design. GetSelection() when there is no selection is expected to return the prompt insertion point. Unlike text editors, if you create a degenerate range earlier in the prompt, then GetSelection(), nothing is expected to happen. This is the equivalent of a sighted user clicking on an editable portion of the prompt. The cursor does not change position.

@carlos-zamora commented on GitHub (Oct 16, 2020): Discussed offline. The issue described is by design. `GetSelection()` when there is no selection is expected to return the prompt insertion point. Unlike text editors, if you create a degenerate range earlier in the prompt, then `GetSelection()`, nothing is expected to happen. This is the equivalent of a sighted user clicking on an editable portion of the prompt. The cursor does not change position.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11050