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

Closing command prompt windows with object nav or mouse causes nvda to exit #1682

Closed
nvaccessAuto opened this issue Jul 21, 2011 · 24 comments · Fixed by #10964
Closed

Closing command prompt windows with object nav or mouse causes nvda to exit #1682

nvaccessAuto opened this issue Jul 21, 2011 · 24 comments · Fixed by #10964

Comments

@nvaccessAuto
Copy link

Reported by briang1 on 2011-07-21 15:58
Launch a command prompt. Use nvda keypad 4 to go to the close button. Use nvda/keypad enter to close the command prompt. Nvda will exit along with the prompt.
I understand that this is due to closing the window in this manner of with a mouse causes windows to close all associated running programs, including nvda.
I did not see a warning about this in the manual, but this might well be me!
Maybe it should be mentioned. Why does not closing it in other ways cause the same problem though?

Very short log pasted for ref only.
INFO - nvda (11:54:55):
Starting NVDA
INFO - core.main (11:54:55):
Config dir: C:\Documents and Settings\brian\Application Data\nvda
DEBUG - core.main (11:54:55):
setting language to Windows
INFO - core.main (11:54:55):
NVDA version 2011.2-4568
INFO - core.main (11:54:55):
Using Windows version sys.getwindowsversion(major=5, minor=1, build=2600, platform=2, service_pack='Service Pack 3')
INFO - core.main (11:54:55):
Using Python version 2.7.2 (default, Jun 12 2011, 15:08:59) v.1500 32 bit (Intel)
INFO - core.main (11:54:55):
Using comtypes version 0.6.2
DEBUG - core.main (11:54:55):
Creating wx application instance
DEBUG - core.main (11:54:55):
Speech Dictionary processing
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
Loading speech dictionary 'C:\Documents and Settings\brian\Application Data\nvda\speechDicts\default.dic'...
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
15 loaded records.
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
Loading speech dictionary 'builtin.dic'...
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
3 loaded records.
DEBUG - core.main (11:54:55):
Initializing speech
INFO - synthDrivers.espeak.SynthDriver.init (11:54:55):
Using eSpeak version 1.45.03 22.Mar.11
DEBUG - speechDictHandler.SpeechDict.load (11:54:56):
Loading speech dictionary 'C:\Documents and Settings\brian\Application Data\nvda\speechDicts\espeak-english.dic'...
DEBUG - speechDictHandler.SpeechDict.load (11:54:56):
file 'C:\Documents and Settings\brian\Application Data\nvda\speechDicts\espeak-english.dic' not found.
INFO - synthDriverHandler.setSynth (11:54:56):
Loaded synthDriver espeak
INFO - core.main (11:54:56):
Using wx version 2.8.11.0 (msw-unicode)
DEBUG - core.main (11:54:56):
Initializing braille
INFO - braille.initialize (11:54:56):
Using liblouis version 2.3.0
INFO - braille.BrailleHandler.setDisplayByName (11:54:56):
Loaded braille display driver noBraille
DEBUG - core.main (11:54:56):
Initializing NVDAHelper
DEBUG - core.main (11:54:56):
Initializing displayModel
DEBUG - core.main (11:54:56):
Initializing GUI
DEBUG - core.main (11:54:56):
Initializing appModule Handler
DEBUG - core.main (11:54:56):
initializing Java Access Bridge support
DEBUG - core.main (11:54:56):
Initializing winConsole support
DEBUG - core.main (11:54:56):
Initializing UIA support
WARNING - core.main (11:54:56):
UIA not available
DEBUG - core.main (11:54:56):
Initializing IAccessible support
DEBUG - core.main (11:54:56):
Initializing input core
DEBUGWARNING - inputCore.InputManager.loadLocaleGestureMap (11:54:56):
No locale gesture map for language en
DEBUGWARNING - inputCore.InputManager.loadUserGestureMap (11:54:56):
No user gesture map
DEBUG - core.main (11:54:56):
Initializing keyboard handler
DEBUG - core.main (11:54:56):
initializing mouse handler
DEBUG - core.main (11:54:56):
Initializing global plugin handler
DEBUG - core.main (11:54:56):
starting core pump
DEBUG - core.CorePump.init (11:54:56):
Core pump starting
DEBUG - core.main (11:54:56):
Initializing watchdog
INFO - core.main (11:54:56):
NVDA initialized
DEBUG - core.main (11:54:56):
entering wx application main loop
IO - speech.speak (11:54:56):
Speaking Prompt terminal'
IO - speech.speak (11:54:56):
Speaking and Settings\brian> '
IO - inputCore.InputManager.executeGesture (11:55:04):
Input: kb(desktop):NVDA+numpad4
IO - speech.speak (11:55:04):
Speaking button Closes the window 5 of 5'
IO - inputCore.InputManager.executeGesture (11:55:18):
Input: kb(desktop):NVDA+numpadEnter
IO - speech.speak (11:55:18):
Speaking [u'Press']

Its in all versions, development and release that I've tried back to the last two.And that is that.
Blocking #4239, #5343

@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2011-07-21 16:04
Changes:
Changed title from "Closing command prompt windows with object nav or mouse ocauses nvda to exit" to "Closing command prompt windows with object nav or mouse causes nvda to exit"

@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2011-07-21 22:07
When you close it in other ways, NVDA is either notified first or the focus changes before it closes, both of which allow NVDA to detach from the console before it actually closes. Neither of those things happens if you press the Close button at the top of the window.

@nvaccessAuto
Copy link
Author

Comment 3 by mdcurran on 2011-07-21 23:54
According to MSDN we can support ctrl_close_event in our routine handler, returning True which will disable the default handler which calls ExitProcess. However, testing shows that this does not seem to work at all, which I think I remember this also back when we first started writing the console code.

@nvaccessAuto
Copy link
Author

Comment 4 by briang1 on 2011-07-22 13:43
Well, maybe its that nvda has other links to the command process that thwart your approach?

Seems odd to me that it can not only log the command itself but also that its about to say press.... before it gets terminated.

@jcsteh
Copy link
Contributor

jcsteh commented Nov 18, 2015

For the record, I tried detaching from the console in the close handler, having two handlers and detaching in the one that gets called first, and having two handlers and removing the second in the first. All of these failed, with the last one causing a crash with an access violation.

@dkager
Copy link
Collaborator

dkager commented Nov 18, 2015

Are you even supposed to be able to get out of this killing spree? The idea seems to be that you get a little time to clean up, then right when the handler returns the process 'terminates', either through ExitProcess() if the handler returned FALSE or in some unspecified way otherwise. The loophole of freeing the console when you receive Ctrl+Close may not work on purpose.

@jcsteh
Copy link
Contributor

jcsteh commented Nov 18, 2015 via email

@bhavyashah
Copy link

@jcsteh From #1682 (comment), I take It that this issue persists at present, right?

@jcsteh
Copy link
Contributor

jcsteh commented Aug 7, 2017

Yes, this still persists.

@derekriemer
Copy link
Collaborator

@jcsteh kind of disgusting, but could we inject into the functions in windows that close the console and detect this, to tell NVDA to detach before the console murders us?

@jcsteh
Copy link
Contributor

jcsteh commented Aug 14, 2017

Maybe, but I doubt it. As noted in #1682 (comment), detaching from the console within the close handler doesn't help. So, this would have to be done before the close handler, but I'm guessing we don't get notified before the kill unless there's a close handler. I think there's probably a better chance of hooking ExitProcess and making it a no-op for this case, but that is pretty risky and we'd have to be pretty tight about the detection of console exits. Someone would have to do some pretty serious Windows debugging to figure this out.

@Adriani90
Copy link
Collaborator

I can still reproduce this issue on Windows 10 with NVDA 2018.2.1.

cc: @feerrenrut

@derekriemer
Copy link
Collaborator

I don't think we can fix this. We should long term maybe use UIA.

@feerrenrut
Copy link
Contributor

Having not looked into this at all, I'm hesitant to comment. I don't know what causes NVDA to become "associated" with the command prompt, but if we are not able to "disassociate", then another approach might be to use a proxy process which can safely be killed without affecting the rest of NVDA.

@jcsteh
Copy link
Contributor

jcsteh commented Jul 30, 2018

@feerrenrut commented on Jul 30, 2018, 4:46 PM GMT+10:

I don't know what causes NVDA to become "associated" with the command prompt,

The only way to read a console programmatically is to "attach" to it, as if we actually wanted to act as a shell or an application. Once you attach to a console, you become beholden to that console's killing whims.

but if we are not able to "disassociate", then another approach might be to use a proxy process which can safely be killed without affecting the rest of NVDA.

That would work, yes. It'd just be tedious to implement the IPC, which is why it hasn't been done yet. :)

Long-term, using UIA might be an option, but only once the console UIA implementation isn't a steaming pile of excrement and only in versions of Windows 10 without said excrement.

@codeofdusk
Copy link
Contributor

codeofdusk commented Jul 5, 2019

Once #9771 is merged, this issue will be resolved on Windows 10 version 1803 and later, as NVDA does not need to attach to consoles when UIA is available. However, the issue is still present on Windows LTSC/Server 2016 (Windows 10 1607), which will remain supported for many years to come. While it may be possible to separate some of the in-process legacy console code into its own process (which would be safe to kill off, therefore not breaking NVDA), doing so would likely degrade performance. Since the issue is resolved for the latest three Windows versions, I vote to close it.

@feerrenrut
Copy link
Contributor

I don't think this should be closed, there are certainly avenues for fixing this, I'd be very surprised if we couldn't get round trip latency below 20ms for IPC.

Given that Windows Server 2016 support "Extended support end date" is 12th Jan 2027, this will be affecting people for a long time to come.

@Brian1Gaff
Copy link

Brian1Gaff commented Jul 6, 2019 via email

@TechHorseG
Copy link

I inadvertently started a duplicate of this issue recently,and was advised to write here.

It is still the case that in 20H2 closing a running Batch File or Command Prompt via a taskkill command while the console window is in focus, will terminate NVDA also.

This is a bit of a headache for me, as I want to create scripts to auto-close running Batch Files under certain circumstances, and can't easily guarantee that they won't be in focus at the time of their closure.

Clicking the Close button on a Command Prompt also had this consequence when I tried it.

So, just wishing to express an interest in there being a solve for this issue. Thanks.

@codeofdusk
Copy link
Contributor

This is solved (experimentally) in the UIA implementation of Windows Console support. Enable "use UI Automation to access Windows Console when available" in NVDA advanced prefs.

This will be enabled by default in an upcoming Windows release after a bit more polish, see microsoft/terminal#7000 for updates.

@TechHorseG
Copy link

TechHorseG commented Apr 16, 2021

Oh that is good to see! I gave that setting a try and it seems to be doing the job of keeping NVDA alive. Great.

One thing though, you mentioned the need for a bit of polish and I did notice something. So I was wondering if there is any established NVDA thread for discussing NVDA's behaviour with this new setting?

once again, I'm so glad we are approaching a full solve :)

@Adriani90
Copy link
Collaborator

@TechHorseG how is NVDA last alpha behaving now in this situation? Is it still having this issue when not using UIA in Windows Consoles?

@codeofdusk
Copy link
Contributor

Behaviour here is unchanged: this issue is resolved with UIA enabled, which is set to be the default in a future release of conhost (#10964). This new release will probably be the inbox build either in a cumulative update on top of 11 or I'd think part of SV2 at the latest. However, given plans to ship conhost "out-of-box" there are no guarantees about where the update will be available. Cc @DHowett.

@josephsl
Copy link
Collaborator

josephsl commented Aug 18, 2021 via email

seanbudd pushed a commit that referenced this issue Jun 21, 2022
…(Windows 11 Sun Valley 2) (#10964)

Supersedes #9771 and #10716. Closes #1682. Closes #8653. Closes #9867. Closes #11172. Closes #11554.

Summary of the issue:

Microsoft has significantly improved performance and reliability of UIA console:
* microsoft/terminal#4018 is an almost complete rewrite of the UIA code which makes the console's UIA implementation more closely align with the API specification.
* microsoft/terminal#10886, microsoft/terminal#10925, and microsoft/terminal#11253 form a robust testing methodology for the UIA implementation, including bug fixes in response to newly added tests based on Word's UIA implementation.
* microsoft/terminal#11122 removes the thousands of empty lines at the end of the console buffer, significantly improving performance and stability. Since all console text ranges are now within the text buffer's bounds, it is no longer possible for console to crash due to the manipulation by UIA clients of an out-of-bounds text range.
* Countless other accessibility-related PRs too numerous to list here.

We should enable UIA support on new Windows Console builds by default for performance improvement and controllable password suppression.

Description of how this pull request fixes the issue:

This PR:
* Exposes all three options for the UIA console feature flag in the UI (replaces the UIA check box with a combo box).
* Adds a runtime check to test if `apiLevel >= FORMATTED`, and use UIA in this case when the user preference is auto. This is the case on Windows 11 Sun Valley 2 (SV2) available now in beta and set for release in the second half of 2022.
@nvaccessAuto nvaccessAuto modified the milestone: 2022.3 Jun 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet