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

Problems with command consoles and object navigation #673

Closed
nvaccessAuto opened this issue May 26, 2010 · 7 comments · Fixed by #9771
Closed

Problems with command consoles and object navigation #673

nvaccessAuto opened this issue May 26, 2010 · 7 comments · Fixed by #9771
Labels
bug/regression bug feature/windows-command-console p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Milestone
2019.3

Comments

@nvaccessAuto
Copy link

Reported by jteh on 2010-05-26 22:41
When you move to a command console with object navigation, NVDA connects to this console, which allows this console to be reviewed. While this is useful, it presents three problems:

  1. When you move to the console using object navigation, the console is connected, but it isn't disconnected when you move away.
    • This is because there is a becomeNavigatorObject event, but no event for the reverse.
  2. When object navigation causes NVDA to connect to a console, new text is reported for that console. New text should only be reported for focused consoles.
  3. Because only one console can be connected at a time, if a console is focused and the user moves to another console with object navigation, the user can no longer access the focused console. That is, new text is not read nor is caret navigation, backspace, etc.

While issues 1 and 2 can be fixed, it is probably not possible to solve issue 3, as this is due to a limitation of the implementation in Windows. Therefore, the only option may be to not connect to consoles for review.

Work around: To restore functionality to a focused console, move the navigator object back to the focused console.

This functionality was introduced in 4808ab6.
@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2010-09-23 02:59
Changes:
Milestone changed from 2010.3 to None

@nvaccessAuto
Copy link
Author

Comment 2 by jteh (in reply to comment description) on 2010-11-09 09:17
Replying to jteh:

  1. When object navigation causes NVDA to connect to a console, new text is reported for that console. New text should only be reported for focused consoles.

This is fixed in the update to make consoels use the Terminal behavior in the displayModelNewText branch.

  1. When you move to the console using object navigation, the console is connected, but it isn't disconnected when you move away.

This still happens even with the above fix, but it doesn't really matter because it isn't monitored for new text.

The final issue is still unsolvable, as noted earlier.

@LeonarddeR
Copy link
Collaborator

@jcsteh: Can't we tie console connect/disconnect to event_gainFocus/leaveFocus?

@jcsteh
Copy link
Contributor

jcsteh commented Jul 19, 2017

Sure we can. However, that will make it impossible to review non-focused consoles. Still, that's probably the best we can hope for at this stage, so that's probably the solution we should go with.

@jcsteh jcsteh added the p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Jul 19, 2017
@Adriani90
Copy link
Collaborator

Any update on this?

@Adriani90
Copy link
Collaborator

cc: @derekriemer

@codeofdusk codeofdusk mentioned this issue May 23, 2019
Merged
@codeofdusk codeofdusk mentioned this issue Jun 18, 2019
Merged
@codeofdusk
Copy link
Contributor

Once #9771 is merged, this issue will be resolved on Windows 10 version 1803 and later; UIA has no notion of "connecting" to consoles like the legacy support did. However, it is still not fixed on Windows Server and LTSC 2016 (Windows 10 1607), which will still be supported for many years to come. Unfortunately though, since the legacy console support requires that we connect to consoles in this way, we cannot fix the bug on this older release. Since the issue has either been resolved or resolution is impossible, I vote to close it. You are, of course, welcome to investigate further for legacy consoles and propose a solution if one exists!

@nvaccessAuto nvaccessAuto added this to the 2019.3 milestone Aug 2, 2019
feerrenrut pushed a commit that referenced this issue Aug 2, 2019
@codeofdusk @feerrenrut
UI Automation in Windows Console: Make UIA the default for Windows 10…
216e476 
… 1803 and later (PR #9771)

NVDA's UIA console support significantly improves performance and stability, so we should enable it by default.

While UIA in consoles was added in Windows 10 1709, the initial implementation left much to be desired, particularly concerning caret movement and expansion to character.

A new `UIAUtils.shouldUseUIAConsole` function has been added which determines whether to use UIA in consoles:
* If the user has explicitly chosen to use UIA or legacy console support, the function returns `True` or `False` respectively.
* Otherwise, if the user is running at least Windows 10 1803, the function returns `True`, or `False` if not.

The "use UI Automation in the Windows Console when available" GUI setting has been changed to expose all options in the config spec (i.e. to automatically detect UIA/legacy or override this autodetection).

builds on #9614
closes #673
closes #6291
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug/regression bug feature/windows-command-console p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Milestone
2019.3
Development

Successfully merging a pull request may close this issue.

UI Automation in Windows Console: Make UIA the default for Windows 10 1803 and later codeofdusk/nvda
5 participants
@codeofdusk @LeonarddeR @jcsteh @nvaccessAuto @Adriani90