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

Text spam by program or via copy-paste in Python deletes text previously on screen #15347

New Issue
Closed
opened 2026-01-31 04:35:47 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 04:35:47 +00:00
Owner
Copy Link

Originally created by @Uchiha-Senju on GitHub (Sep 25, 2021).

Windows Terminal version (or Windows build number)

Windows Terminal Version: 1.10.2383.0

Other Software

Python 3.9.2
Not an issue using Python with old cmd, or wsl(v2), or wsl(v2) in the Terminal
(wsl : Kernel version: 5.10.16, Default Distribution: Ubuntu-20.04)

Steps to reproduce

  1. Enter Python console
  2. Known trigger inputs :
    1. Press Enter to display the python prompt again and again, at any rate
    2. Copy and paste a large amount of text such that Python doesn't respond with any variable text, only pre-determined text
      1. One example is to enter a while loop with input("input : "), etc.
      2. Otherwise one can copy text spanning only 1 line

Expected Behavior

The text simply scrolls down with the new input while the text previously on display is still accessible by scrolling upwards.

Actual Behavior

Previous text gets deleted at a boundary defined by where the top of the screen was when the copy-paste/Enter spam was initiated.

To illustrate :

  • Enter spam + single-line copy-paste
    wut
  • while input("") + multi-line copy-paste
    no_buffer
  • Null case : multi-line copy-paste triggering Python's error message output
    okay_buffer
Originally created by @Uchiha-Senju on GitHub (Sep 25, 2021). ### Windows Terminal version (or Windows build number) Windows Terminal Version: 1.10.2383.0 ### Other Software Python 3.9.2 Not an issue using Python with old `cmd`, or `wsl`(v2), or `wsl`(v2) in the Terminal (wsl : Kernel version: 5.10.16, Default Distribution: Ubuntu-20.04) ### Steps to reproduce 1. Enter Python console 2. Known trigger inputs : 1. Press <kbd>Enter</kbd> to display the python prompt again and again, at any rate 2. Copy and paste a large amount of text such that Python doesn't respond with any variable text, only pre-determined text 1. One example is to enter a while loop with `input("input : ")`, etc. 2. Otherwise one can copy text spanning only 1 line ### Expected Behavior The text simply scrolls down with the new input while the text previously on display is still accessible by scrolling upwards. ### Actual Behavior Previous text gets deleted at a boundary defined by where the top of the screen was when the copy-paste/<kbd>Enter</kbd> spam was initiated. To illustrate : - <kbd>Enter</kbd> spam + single-line copy-paste ![wut](https://drive.google.com/uc?export=view&id=19lkmcUie4IQyP-2eRNsRcdvrlIxehp7W) - while `input("")` + multi-line copy-paste ![no_buffer](https://drive.google.com/uc?export=view&id=1MHXdsWycD-UPDPjs0P10Rb4Ijx5_0DXy) - Null case : multi-line copy-paste triggering Python's error message output ![okay_buffer](https://drive.google.com/uc?export=view&id=16nWuI09fWNAH9Ww9pYiIiXnMD0PkdOPn)
claunia added the Needs-TriageResolution-ExternalNeeds-Tag-FixNeeds-Attention labels 2026-01-31 04:35:48 +00:00
claunia commented 2026-01-31 04:35:49 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 27, 2021):

That's so weird. To be clear, you're using the Windows python install here, not the WSL one? (EDIT: finding the start of the gif, this does seem to be true)

This looks like a scrolling margins bug, but if this is the Windows python then I wouldn't expect that at all. Nor would I expect this to have regressed recently. I also can't get this to repro in python 3.9.7 locally.

Does this repro when using python (instead of py)? What do you have your historySize set to? Are you resizing the window at all before doing this? Does selecting text in the Terminal seem to make it all snap to the correct state (this one's a long shot)? Does this work in a PowerShell tab (instead of a command prompt tab)?

I'm grasping at straws here trying to find something that might be relevant.

@zadjii-msft commented on GitHub (Sep 27, 2021): That's so weird. To be clear, you're using the Windows python install here, not the WSL one? (EDIT: finding the start of the gif, this does seem to be true) This looks like a scrolling margins bug, but if this is the Windows python then I wouldn't expect that at all. Nor would I expect this to have regressed recently. I also can't get this to repro in python `3.9.7` locally. Does this repro when using `python` (instead of `py`)? What do you have your `historySize` set to? Are you resizing the window at all before doing this? Does selecting text in the Terminal seem to make it all snap to the correct state (this one's a long shot)? Does this work in a PowerShell tab (instead of a command prompt tab)? I'm grasping at straws here trying to find something that might be relevant.
claunia commented 2026-01-31 04:35:50 +00:00
Author
Owner
Copy Link

@Uchiha-Senju commented on GitHub (Sep 27, 2021):

  • Perfectly identical with python I have found
  • I have never changed it, that I know. Found it in the profile's Advanced section set to 9001. It is not set in settings.json, so seems to be default. I'll attach the file here for reference. To summarize my edits to it : I added Afterglow.
    settings.txt
    w.
  • Bugs out on a freshly opened window too, as well one which has been resized. Resizing also preserves what history has been left.
  • Copying doesn't update the state, a no-go.
  • Yes, I had tested it in PS too, forgot to mention (apologies!)
    • As mentioned in the Software section, it only bugs when through Windows Terminal, not directly using powershell

I'll also expand the trigger behaviour set by adding a file. Making this, I notice that simply typing in the code and hitting Enter also results in line deletion. Running a .py file, I can see that it must be a problem with the interactive console, as all behaviour is normal (been troubleshooting a CLI game made on C++, so other languages should be ok too).
Interestingly, time.sleep(1) doesn't affect the behaviour, just gives us time to scroll up and see the deletion happen, while sys.stdin.readline() does not cause any issues, so perhaps the problem in input's proverbial bells and whistles?
test_cases.txt

Input 0 , half-deletor behaviour :
half-deletor.gif

@Uchiha-Senju commented on GitHub (Sep 27, 2021): - Perfectly identical with `python` I have found - I have never changed it, that I know. Found it in the profile's Advanced section set to [9001](https://www.youtube.com/watch?v=QsDDXSmGJZA). It is not set in `settings.json`, so seems to be default. I'll attach the file here for reference. To summarize my edits to it : I added Afterglow. [settings.txt](https://github.com/microsoft/terminal/files/7238863/settings.txt) w. - Bugs out on a freshly opened window too, as well one which has been resized. Resizing also preserves what history has been left. - Copying doesn't update the state, a no-go. - Yes, I had tested it in PS too, forgot to mention (apologies!) - As mentioned in the Software section, it only bugs when through Windows Terminal, not directly using `powershell` I'll also expand the trigger behaviour set by adding a file. Making this, I notice that simply typing in the code and hitting <kbd>Enter</kbd> also results in line deletion. Running a .py file, I can see that it must be a problem with the interactive console, as all behaviour is normal (been troubleshooting a CLI game made on C++, so other languages should be ok too). Interestingly, `time.sleep(1)` doesn't affect the behaviour, just gives us time to scroll up and see the deletion happen, while `sys.stdin.readline()` does not cause any issues, so perhaps the problem in `input`'s proverbial bells and whistles? [test_cases.txt](https://github.com/microsoft/terminal/files/7239308/test_cases.txt) Input 0 , half-deletor behaviour : ![half-deletor.gif](https://drive.google.com/uc?export=view&id=1PdDyCLwYEgu4UmasPhtL0RUwcYPts88M)
claunia commented 2026-01-31 04:35:50 +00:00
Author
Owner
Copy Link

@wdomon commented on GitHub (Nov 10, 2021):

Slight variation to this problem. Running Windows Powershell (5.1), whatever was showing as the top line of the console window is deleted from the prior output when a new command is run. Very hard to describe as it seems to me to be a very strange bug so here's a GIF as an example (running on Version: 1.11.2921.0).

sjwcjgheLJ

@wdomon commented on GitHub (Nov 10, 2021): Slight variation to this problem. Running Windows Powershell (5.1), whatever was showing as the top line of the console window is deleted from the *prior* output when a new command is run. Very hard to describe as it seems to me to be a very strange bug so here's a GIF as an example (running on Version: 1.11.2921.0). ![sjwcjgheLJ](https://user-images.githubusercontent.com/27928450/141180729-0cab38a9-ca97-4fd6-b7ea-ba69c1fbdbe8.gif)
claunia commented 2026-01-31 04:35:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 10, 2021):

Slight variation to this problem. Running Windows Powershell (5.1), whatever was showing as the top line of the console window is deleted from the prior output when a new command is run. Very hard to describe as it seems to me to be a very strange bug so here's a GIF as an example (running on Version: 1.11.2921.0).

This is a known issue in Windows PowerShell 5.1, the version that is stuck in-box with Windows. It tells us to "scroll the screen," which is an operation that usually destroys the top line in a compliant terminal. That was tracked and fixed for PowerShell 7. More info, and a GIF that reproduces it in a funny/visible way, is available at https://github.com/PowerShell/PSReadLine/issues/724

(I'll minimize these two comments.)

@DHowett commented on GitHub (Nov 10, 2021): > Slight variation to this problem. Running Windows Powershell (5.1), whatever was showing as the top line of the console window is deleted from the _prior_ output when a new command is run. Very hard to describe as it seems to me to be a very strange bug so here's a GIF as an example (running on Version: 1.11.2921.0). This is a known issue in Windows PowerShell 5.1, the version that is stuck in-box with Windows. It tells us to "scroll the screen," which is an operation that usually destroys the top line in a compliant terminal. That was tracked and fixed for PowerShell 7. More info, and a GIF that reproduces it in a funny/visible way, is available at https://github.com/PowerShell/PSReadLine/issues/724 (I'll minimize these two comments.)
claunia commented 2026-01-31 04:35:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 10, 2021):

Actually, though... I wonder if the Python issue here has the same root cause (!).

Using the same repro methodology used to illustrate that PowerShell was doing something weird: it does look like Python is using ScrollConsoleScreenBuffer or CSI S.

python-scroll-buffer

@DHowett commented on GitHub (Nov 10, 2021): Actually, though... I wonder if the Python issue here has the same root cause (!). Using the same repro methodology used to illustrate that PowerShell was doing something weird: it _does_ look like Python is using `ScrollConsoleScreenBuffer` or `CSI S`. ![python-scroll-buffer](https://user-images.githubusercontent.com/189190/141183601-93090378-4638-4316-b70c-e7aff21bc5f7.gif)
claunia commented 2026-01-31 04:35:51 +00:00
Author
Owner
Copy Link

@eryksun commented on GitHub (Nov 11, 2021):

Normally Python's REPL shell is a simple consumer of ReadConsoleW() and WriteConsoleW().

I see buggy behavior only if the third-party pyreadline package is installed. Some packages might depend on it. The readline module gets imported when the interpreter executes in interactive mode, unless isolated mode is enabled. Check whether the following is true: import sys; 'readline' in sys.modules. Also, check whether the problem goes away in isolated mode: python3.9.exe -I.

@eryksun commented on GitHub (Nov 11, 2021): Normally Python's REPL shell is a simple consumer of `ReadConsoleW()` and `WriteConsoleW()`. I see buggy behavior only if the third-party pyreadline package is installed. Some packages might depend on it. The readline module gets imported when the interpreter executes in interactive mode, unless isolated mode is enabled. Check whether the following is true: `import sys; 'readline' in sys.modules`. Also, check whether the problem goes away in isolated mode: `python3.9.exe -I`.
claunia commented 2026-01-31 04:35:51 +00:00
Author
Owner
Copy Link

@Uchiha-Senju commented on GitHub (Jul 18, 2022):

Check whether the following is true: import sys; 'readline' in sys.modules. Also, check whether the problem goes away in isolated mode: python3.9.exe -I.

Indeed, the hunch is right, no problems in isolated mode. Also the IO seems faster.
isolated_mode_test

@Uchiha-Senju commented on GitHub (Jul 18, 2022): > Check whether the following is true: `import sys; 'readline' in sys.modules`. Also, check whether the problem goes away in isolated mode: `python3.9.exe -I`. Indeed, the hunch is right, no problems in isolated mode. Also the IO seems faster. ![isolated_mode_test](https://user-images.githubusercontent.com/19309745/179527229-e5202f23-291d-4ec1-bb10-83d0968cac0f.gif)
claunia commented 2026-01-31 04:35:51 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 14, 2022):

I see buggy behavior only if the third-party pyreadline package is installed. Some packages might depend on it. The readline module gets imported when the interpreter executes in interactive mode, unless isolated mode is enabled. Check whether the following is true: import sys; 'readline' in sys.modules. Also, check whether the problem goes away in isolated mode: python3.9.exe -I.

Indeed, the hunch is right, no problems in isolated mode. Also the IO seems faster.

Wow okay sorry for letting this linger. We never saw the conclusion here!

This should totally be reported downstream, probably on pyreadline.

Thanks for the help!

@zadjii-msft commented on GitHub (Dec 14, 2022): > I see buggy behavior only if the third-party pyreadline package is installed. Some packages might depend on it. The readline module gets imported when the interpreter executes in interactive mode, unless isolated mode is enabled. Check whether the following is true: `import sys; 'readline' in sys.modules`. Also, check whether the problem goes away in isolated mode: `python3.9.exe -I`. > Indeed, the hunch is right, no problems in isolated mode. Also the IO seems faster. Wow okay sorry for letting this linger. We never saw the conclusion here! This should totally be reported downstream, probably on `pyreadline`. Thanks for the help!
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 Needs-Attention Needs-Tag-Fix Needs-Triage Resolution-External
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#15347
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?