starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-09 02:26:45 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Crash when attempting to compare selection endpoints with UIA #7352

New Issue
Closed
opened 2026-01-31 01:01:45 +00:00 by claunia · 15 comments
claunia commented 2026-01-31 01:01:45 +00:00
Owner
Copy Link

Originally created by @codeofdusk on GitHub (Apr 10, 2020).

Originally assigned to: @carlos-zamora on GitHub.

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)!

Originally created by @codeofdusk on GitHub (Apr 10, 2020). Originally assigned to: @carlos-zamora on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none 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](http://nvda-project.org/snapshots). 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. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior Windows Console crashes, and the following is written to the NVDA log: ```none 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)!
claunia commented 2026-01-31 01:01:46 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 10, 2020):

Cc @carlos-zamora @DHowett-MSFT.

@codeofdusk commented on GitHub (Apr 10, 2020): Cc @carlos-zamora @DHowett-MSFT.
claunia commented 2026-01-31 01:01:46 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 10, 2020):

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

@codeofdusk commented on GitHub (Apr 10, 2020): For whatever it's worth, this doesn't crash Windows Terminal.
claunia commented 2026-01-31 01:01:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 10, 2020):

(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 ☺️ )

@zadjii-msft commented on GitHub (Apr 10, 2020): (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 ☺️ )
claunia commented 2026-01-31 01:01:46 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Apr 11, 2020):

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

@DHowett-MSFT commented on GitHub (Apr 11, 2020): Thanks! Marking it triaged. @carlos-zamora ACK if you've seen it.
claunia commented 2026-01-31 01:01:47 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Apr 11, 2020):

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

@carlos-zamora commented on GitHub (Apr 11, 2020): Yep! I was taking a look at it a bit today. This one is kind of surprising.
claunia commented 2026-01-31 01:01:47 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 13, 2020):

Running nano also causes the crash.

@codeofdusk commented on GitHub (Apr 13, 2020): Running `nano` also causes the crash.
claunia commented 2026-01-31 01:01:47 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Apr 13, 2020):

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?

@carlos-zamora commented on GitHub (Apr 13, 2020): 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 `UiaTextRange`s 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?
claunia commented 2026-01-31 01:01:48 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 13, 2020):

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.

@codeofdusk commented on GitHub (Apr 13, 2020): 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.
claunia commented 2026-01-31 01:01:48 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Apr 13, 2020):

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.

@DHowett-MSFT commented on GitHub (Apr 13, 2020): 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.
claunia commented 2026-01-31 01:01:48 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 13, 2020):

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 commented on GitHub (Apr 13, 2020): > 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.
claunia commented 2026-01-31 01:01:48 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 16, 2020):

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

@codeofdusk commented on GitHub (Apr 16, 2020): Also cc @leonardder (author of nvaccess/nvda#9660). Could you please provide advice here?
claunia commented 2026-01-31 01:01:48 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 17, 2020):

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 commented on GitHub (Apr 17, 2020): 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!
claunia commented 2026-01-31 01:01:49 +00:00
Author
Owner
Copy Link

@codeofdusk commented on GitHub (Apr 17, 2020):

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))
@codeofdusk commented on GitHub (Apr 17, 2020): 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`: ```python >>> 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)) ```
claunia commented 2026-01-31 01:01:49 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Apr 17, 2020):

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.

@DHowett-MSFT commented on GitHub (Apr 17, 2020): 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_.
claunia commented 2026-01-31 01:01:49 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 5, 2020):

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

Handy links:

@ghost commented on GitHub (May 5, 2020): :tada: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](https://github.com/microsoft/terminal/releases/tag/v0.11.1251.0 (1.0rc1)) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Accessibility Issue-Bug Product-Conhost Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#7352
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?