Crash when attempting to compare selection endpoints with UIA

[codeofdusk]

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd] 21H1 (19603.1000)
Windows Terminal version (if applicable): inbox console

Any other software? NVDA 2020.2

Steps to reproduce

1. Start the latest NVDA alpha snapshot.
2. In NVDA advanced settings, enable "use UI Automation to access the Windows Console when available".
3. Open cmd.
4. Ssh to an Ubuntu 18.04 system.
5. Run sudo do-release-upgrade -d.

Expected behavior

NVDA reads the output, and the console remains functional.

Actual behavior

Windows Console crashes, and the following is written to the NVDA log:

ERROR - eventHandler.executeEvent (04:42:19.980) - MainThread (21752):
error executing event: caret on <NVDAObjects.Dynamic_WinConsoleUIAEditableTextWithAutoSelectDetectionUIA object at 0x070733B0> with extra args of {}
Traceback (most recent call last):
  File "eventHandler.pyc", line 155, in executeEvent
  File "eventHandler.pyc", line 92, in __init__
  File "eventHandler.pyc", line 100, in next
  File "NVDAObjects\behaviors.pyc", line 191, in event_caret
  File "editableText.pyc", line 333, in detectPossibleSelectionChange
  File "editableText.pyc", line 340, in _updateSelectionAnchor
  File "NVDAObjects\UIA\__init__.pyc", line 776, in compareEndPoints
  File "comtypesMonkeyPatches.pyc", line 26, in __call__
_ctypes.COMError: (-2147418113, 'Catastrophic failure', (None, None, None, 0, None))

Context

NVDA uses cursor changed events to detect and report selection changes to the user. It receives a cursor change event and compares the previous and current selection endpoints, which causes console to crash in this case. Is there anything I can do to help trace this on the console side?

Please push the fix for this issue to 21H1 as we'd really like to use UIA in console (especially after the excellent work in #4018 and #4495)!

[codeofdusk]

Cc @carlos-zamora @DHowett-MSFT.

[codeofdusk]

For whatever it's worth, this doesn't crash Windows Terminal.

[zadjii-msft]

(tentatively throwing this in the 21H1 milestone, but that's totally arbitrary. I figured this is a conhost bug, not a Terminal bug, so that's where it belongs. The team can overrule me ☺️ )

[DHowett-MSFT]

Thanks! Marking it triaged. @carlos-zamora ACK if you've seen it.

[carlos-zamora]

Yep! I was taking a look at it a bit today. This one is kind of surprising.

[codeofdusk]

Running nano also causes the crash.

[carlos-zamora]

Took a closer look at this today. It looks like the root cause is that when we switch over to the alt buffer, we are now in a state where the buffer size may have changed. So when you compare a COORD 'A' from the main buffer to another COORD 'B' from the alt buffer, 'A' may not fit in the alt buffer. This makes the comparison invalid, but a crash on our end is definitely not right.

@DHowett-MSFT suggested that we track which buffer the UiaTextRange came from. Then, when two UiaTextRanges are compared, we first ensure that they came from the same buffer.

We could probably return a relevant HRESULT instead. @codeofdusk is there anything you've seen in other apps that you can expect here?

[codeofdusk]

What do you mean by the alt buffer? If the console is switching buffers, this also might explain some issues I've been seeing with GetVisibleRanges that I haven't been able to consistently reproduce.

[DHowett-MSFT]

To ask more succinctly: how do we respond to say "this comparison is simply invalid. it takes place in two different coordinate systems."?

The alt buffer is a different "screen mode" for terminal applications. It hides whatever was on the screen prior and lets the application have its own sandbox. Once the application is done, it will turn off the alt buffer, permanently destroying its contents.

[codeofdusk]

To ask more succinctly: how do we respond to say "this comparison is simply invalid. it takes place in two different coordinate systems."?

The alt buffer is a different "screen mode" for terminal applications. It hides whatever was on the screen prior and lets the application have its own sandbox. Once the application is done, it will turn off the alt buffer, permanently destroying its contents.

Cc @michaelDCurran.

[codeofdusk]

Also cc @LeonarddeR (author of nvaccess/nvda#9660). Could you please provide advice here?

[codeofdusk]

Sorry, I'm not familiar enough with UIA to answer. Generally, applications I've seen don't have text ranges that behave like this (i.e. two text ranges from the same text where comparison is incompatible). A crash is definitely not the right thing to do though!

[codeofdusk]

For whatever it's worth, it does seem that, when I open a word document, get the text range for the document, open a second document, get that text range, and compare endpoints of the two ranges (from separate documents) it returns null:

>>> ti=nav.makeTextInfo("all") # First document
>>> ti2=nav.makeTextInfo("all") # Second document
>>> ti.compareEndPoints(ti2,"endToStart")
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "NVDAObjects\UIA\__init__.pyc", line 776, in compareEndPoints
  File "comtypesMonkeyPatches.pyc", line 26, in __call__
_ctypes.COMError: (-2146233079, None, (None, None, None, 0, None))

[DHowett-MSFT]

Interesting. If that won’t throw off the works, that might be good for us. Ideally, in the long term, we would have different UIA parent objects for the different text buffers.

[ghost]

🎉This issue was addressed in #5399, which has now been successfully released as Windows Terminal Release Candidate v0.11.1251.0 (1.0rc1).:tada:

Handy links:

• Release Notes
• Store Download