starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Sporadic cannot ctrl+D to or enter to close the terminal #21979

New Issue
Closed
opened 2026-01-31 07:59:52 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 07:59:52 +00:00
Owner
Copy Link

Originally created by @dovholuknf on GitHub (Jul 17, 2024).

Windows Terminal version

Version: 1.21.1772.0

Windows build number

Microsoft Windows [Version 10.0.22631.3880]

Other Software

N/A

Steps to reproduce

No idea how to reproduce. Sometimes, after a long time open and running I notice the "track my mouse" feature stops working between panes and then when i exit the terminal it ends up printing:

[process exited with code 130 (0x00000082)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

but ctrl+d or enter don't exit the pane:
terminal-pane-example

Expected Behavior

I want the "track my mouse" feature to keep working and if i have to close the terminal, i expect the pane to actually close.

Actual Behavior

mouse tracking fails and ctrl+d/enter won't actually close the pane. the whole terminal window needs to be relaunched.

Originally created by @dovholuknf on GitHub (Jul 17, 2024). ### Windows Terminal version Version: 1.21.1772.0 ### Windows build number Microsoft Windows [Version 10.0.22631.3880] ### Other Software N/A ### Steps to reproduce No idea how to reproduce. Sometimes, after a long time open and running I notice the "track my mouse" feature stops working between panes and then when i exit the terminal it ends up printing: ``` [process exited with code 130 (0x00000082)] You can now close this terminal with Ctrl+D, or press Enter to restart. ``` but ctrl+d or enter don't exit the pane: ![terminal-pane-example](https://github.com/user-attachments/assets/7b66b6b6-39a4-4ad6-8de0-e95adf8bfb50) ### Expected Behavior I want the "track my mouse" feature to keep working and if i have to close the terminal, i expect the pane to actually close. ### Actual Behavior mouse tracking fails and ctrl+d/enter won't actually close the pane. the whole terminal window needs to be relaunched.
claunia commented 2026-01-31 07:59:54 +00:00
Author
Owner
Copy Link

@dovholuknf commented on GitHub (Jul 26, 2024):

I can't reproduce it on demand but it keeps happening. i did however go back to the released Version: 1.20.11781.0 and this is not a problem. I've moved away from the 'preview' for now because of this issue.

It might have to do with mouse tracking. Another example of how the mouse tracking seems to have failed and when i exit the terminal i get the Ctrl+D message

track

@dovholuknf commented on GitHub (Jul 26, 2024): I can't reproduce it on demand but it keeps happening. i did however go back to the released Version: 1.20.11781.0 and this is not a problem. I've moved away from the 'preview' for now because of this issue. It might have to do with mouse tracking. Another example of how the mouse tracking seems to have failed and when i exit the terminal i get the Ctrl+D message ![track](https://github.com/user-attachments/assets/1643cc27-3c36-4b63-9d89-9e0a449599c7)
claunia commented 2026-01-31 07:59:54 +00:00
Author
Owner
Copy Link

@dovholuknf commented on GitHub (Jul 29, 2024):

CTRL-D doesn't close the window either on the preview version. I can confirm that the 'stable' terminal 1.20.11781.0 properly responds to CTRL-D and closes the pane

@dovholuknf commented on GitHub (Jul 29, 2024): CTRL-D doesn't close the window either on the preview version. I can confirm that the 'stable' terminal `1.20.11781.0` properly responds to CTRL-D and closes the pane
claunia commented 2026-01-31 07:59:55 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Aug 19, 2024):

I can repro (every time) like this.

Start WT normally (one tab, normal window).
Go full-screen (F11).
Split vertical (Alt+Shift++)
"exit" the shell on the right (this is OK)
"exit" the remaining shell (error occurs)

Note that exiting the lefthand shell then the other one does not cause the error.

Ditto for Split Horizontal with "bottom" replacing "right" and the analogous note about which is exitted first.

@vefatica commented on GitHub (Aug 19, 2024): I can repro (every time) like this. Start WT normally (one tab, normal window). Go full-screen (F11). Split vertical (Alt+Shift++) "exit" the shell on the right (this is OK) "exit" the remaining shell (error occurs) Note that exiting the lefthand shell then the other one does not cause the error. Ditto for Split Horizontal with "bottom" replacing "right" and the analogous note about which is exitted first.
claunia commented 2026-01-31 07:59:55 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Aug 19, 2024):

It happens in WindowsTerminal 1.21.2406.25002 (preview) and not in WindowsTerminal 1.20.2406.26001.

@vefatica commented on GitHub (Aug 19, 2024): It happens in WindowsTerminal 1.21.2406.25002 (preview) and not in WindowsTerminal 1.20.2406.26001.
claunia commented 2026-01-31 07:59:55 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 20, 2024):

This regressed in 5d46e317b2. Because the content isn't being reset anymore, after a split-pane two panes may share the same content object. Closing one pane will then cause both to be closed.

@lhecker commented on GitHub (Aug 20, 2024): This regressed in 5d46e317b29a709a4b585ab9fe83ad71c456b5df. Because the content isn't being reset anymore, after a split-pane two panes may share the same content object. Closing one pane will then cause both to be closed.
claunia commented 2026-01-31 07:59:55 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Aug 20, 2024):

@lhecker, If I understand your comment correctly (which may not be the case), then I don't see that. In my experiment, closing either pane leaves the other pane functional. As noted before, closing the new pane causes the original pane to exhibit the problem under discussion when it's closed. But closing the original pane does not cause the new pane to exhibit the problem when it's closed.

@vefatica commented on GitHub (Aug 20, 2024): @lhecker, If I understand your comment correctly (which may not be the case), then I don't see that. In my experiment, closing either pane leaves the other pane functional. As noted before, closing the new pane causes the original pane to exhibit the problem under discussion _when it's closed_. But closing the original pane does not cause the new pane to exhibit the problem _when it's closed_.
claunia commented 2026-01-31 07:59:55 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 20, 2024):

When I said "closed" I was referring to an internal function called "Close" that removes some event handlers from the "content" of a pane. This is what causes Ctrl-D and Enter to seemingly not work. (It was confusingly worded. I'm sorry. 😣)

@lhecker commented on GitHub (Aug 20, 2024): When I said "closed" I was referring to an internal function called "Close" that removes some event handlers from the "content" of a pane. This is what causes Ctrl-D and Enter to seemingly not work. (It was confusingly worded. I'm sorry. 😣)
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-UserInterface In-PR Issue-Bug Needs-Repro Needs-Tag-Fix Priority-2 Product-Terminal
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#21979
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?