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

[Uchiha-Senju]

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
  
• while input("") + multi-line copy-paste
  
• Null case : multi-line copy-paste triggering Python's error message output
  

[zadjii-msft]

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.

[Uchiha-Senju]

• 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 :

[DHowett]

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.

[eryksun]

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.

[Uchiha-Senju]

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.

[zadjii-msft]

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!