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

Alternate screen shouldn't write to scrollback or normal screen #4877

New Issue
Closed
opened 2026-01-30 23:58:54 +00:00 by claunia · 2 comments
claunia commented 2026-01-30 23:58:54 +00:00
Owner
Copy Link

Originally created by @egmontkob on GitHub (Nov 8, 2019).

Environment

Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.6.2951.0

Epic

Scrollback handling should be just like in VTE because that's the best (ahem ahem) 🤣

Steps to reproduce 1

  • ssh to a Linux box, and execute these:

    seq -f 'normal %.f' 100
echo -ne '\e[?1049h' # switch to alt screen
seq -f 'alt %.f' 100
echo -ne '\e[?1049l' # switch back to normal screen

  • scroll back and examine the contents

Expected behavior 1

Outputs of these two seqs shouldn't interleave

Actual behavior 1

Output consists of normal 1 to normal 74 (exact number depends on the window height), followed by alt 1 to alt 74, and finally normal 75 to normal 100. (alt 75 onwards are gone.)

Steps to reproduce 2

  • ssh to a Linux box.
  • produce a few pages of output
  • start a fullscreen app such as mc
  • resize the window in various ways (maybe even back and forth to smaller and then bigger)
  • quit mc
  • examine the output, including the scrollback

Expected behavior 2

This should look okay (see below).

Actual behavior 2

The contents seem quite garbled. Most of the time you'll see remains of mc's user interface in the scrollback buffer; sometimes even on the normal screen (this latter is harder to reproduce, and perhaps only happens with solid background colors).

VTE rocks

The way this works amazingly in gnome-terminal is:

The alternate screen is pretty much only used by fullscreen apps that control the entire UI and repaint on window resize. Therefore it's unrelated to the normal screen and the scrollback. Data never travels between the (normal screen + scrollback) combo and the alternate screen. The scrollback buffer belongs to the normal screen only. Everything scrolled out from the alternate screen is lost for good.

On resize, the (normal screen + scrollback) is resized as a single unit, for the resizing operation it doesn't matter where the boundary is.

The (normal screen + scrollback) combo is resized the same way, regardless of whether it's the active one or the alternate screen is shown. Stress-test this: produce output on the normal screen, switch to the alternate one (e.g. mc), resize, quit mc. The normal screen's contents will be updated to the new width just as if you haven't switched to the alternate screen.

There's plenty of further tiny details to this story, e.g. how to vertically position the contents, some of which are documented in VTE's doc/rewrap.txt.

Of course there's no specification anywhere that all this has to behave like this. It's just what I believe makes the most sense. Obviously my opinion is quite biased since this was my first big contribution to VTE. :) Luckily I only had to do the rewrapping; the separation of the (normal screen + scrollback) vs. alternate screen was already as desired.

Originally created by @egmontkob on GitHub (Nov 8, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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: 10.0.18362.0 Windows Terminal version (if applicable): 0.6.2951.0 ``` # Epic Scrollback handling should be just like in VTE because that's the best (ahem ahem) :rofl: # Steps to reproduce 1 - `ssh` to a Linux box, and execute these: seq -f 'normal %.f' 100 echo -ne '\e[?1049h' # switch to alt screen seq -f 'alt %.f' 100 echo -ne '\e[?1049l' # switch back to normal screen - scroll back and examine the contents # Expected behavior 1 Outputs of these two `seq`s shouldn't interleave # Actual behavior 1 Output consists of `normal 1` to `normal 74` (exact number depends on the window height), followed by `alt 1` to `alt 74`, and finally `normal 75` to `normal 100`. (`alt 75` onwards are gone.) # Steps to reproduce 2 - `ssh` to a Linux box. - produce a few pages of output - start a fullscreen app such as `mc` - resize the window in various ways (maybe even back and forth to smaller and then bigger) - quit `mc` - examine the output, including the scrollback # Expected behavior 2 This should look okay (see below). # Actual behavior 2 The contents seem quite garbled. Most of the time you'll see remains of `mc`'s user interface in the scrollback buffer; sometimes even on the normal screen (this latter is harder to reproduce, and perhaps only happens with solid background colors). --- # VTE rocks The way this works amazingly in gnome-terminal is: The alternate screen is pretty much only used by fullscreen apps that control the entire UI and repaint on window resize. Therefore it's unrelated to the normal screen and the scrollback. Data never travels between the (normal screen + scrollback) combo and the alternate screen. The scrollback buffer belongs to the normal screen only. Everything scrolled out from the alternate screen is lost for good. On resize, the (normal screen + scrollback) is resized as a single unit, for the resizing operation it doesn't matter where the boundary is. The (normal screen + scrollback) combo is resized the same way, regardless of whether it's the active one or the alternate screen is shown. Stress-test this: produce output on the normal screen, switch to the alternate one (e.g. `mc`), resize, quit `mc`. The normal screen's contents will be updated to the new width just as if you haven't switched to the alternate screen. There's plenty of further tiny details to this story, e.g. how to vertically position the contents, some of which are documented in [VTE's doc/rewrap.txt](https://gitlab.gnome.org/GNOME/vte/blob/master/doc/rewrap.txt). Of course there's no specification anywhere that all this has to behave like this. It's just what I believe makes the most sense. Obviously my opinion is quite biased since this was my first big contribution to VTE. :) Luckily I only had to do the rewrapping; the separation of the (normal screen + scrollback) vs. alternate screen was already as desired.
claunia commented 2026-01-30 23:58:55 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Nov 8, 2019):

This is actually one of the unfortunate circumstances of the pseudoconsole API.

conhost implements the alt buffer reasonably well (we think): it turns off scrollback, reflow, and so on.
When it remotes the contents of the screen as VT over pseudoconsole we're not also sending the alt buffer state down the wire (#381).

@DHowett-MSFT commented on GitHub (Nov 8, 2019): This is actually one of the unfortunate circumstances of the pseudoconsole API. conhost implements the alt buffer reasonably well (we think): it turns off scrollback, reflow, and so on. When it remotes the contents of the screen as VT over pseudoconsole we're not _also_ sending the alt buffer state down the wire (#381).
claunia commented 2026-01-30 23:58:55 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 24, 2022):

:tada:This issue was addressed in #12561, which has now been successfully released as Windows Terminal Preview v1.14.143.🎉

Handy links:

@ghost commented on GitHub (May 24, 2022): :tada:This issue was addressed in #12561, which has now been successfully released as `Windows Terminal Preview v1.14.143`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.14.143) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?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-Output Area-TerminalControl Issue-Bug Needs-Tag-Fix Priority-1 Product-Conpty Product-Terminal 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#4877
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?