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

[Regression] Scrolling and (sometimes) selection stops working with abduco #17607

New Issue
Closed
opened 2026-01-31 05:47:36 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 05:47:36 +00:00
Owner
Copy Link

Originally created by @davidchisnall on GitHub (May 31, 2022).

Windows Terminal version

1.14.1452.0

Windows build number

10.0.22000.675

Other Software

OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f 31 Mar 2020 inside WSL1
abduco-0.6

Steps to reproduce

  1. Start windows terminal.
  2. ssh to a remote machine
  3. Run abduco -A {some session name}

I do not have abduco installed locally and it seems to not be in the repos for the distro that WSL is using, so I have not validated whether step 2 is necessary.

Expected Behavior

Scrolling to continue working.

Actual Behavior

The scrollbar is greyed out and I am no longer able to scroll using them or with the mouse wheel. On a FreeBSD remote system, I am also no longer able to select text sometimes, but at other times it works. With a Linux remote system, I have not seen this second behaviour.

Switching back to the non-preview build that I have installed, 1.12.10983.0, appears to fix the issue.

Happy to share a screen if that would help, feel free to ping me on Teams.

Originally created by @davidchisnall on GitHub (May 31, 2022). ### Windows Terminal version 1.14.1452.0 ### Windows build number 10.0.22000.675 ### Other Software OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f 31 Mar 2020 inside WSL1 abduco-0.6 ### Steps to reproduce 1. Start windows terminal. 2. ssh to a remote machine 3. Run abduco -A {some session name} I do not have abduco installed locally and it seems to not be in the repos for the distro that WSL is using, so I have not validated whether step 2 is necessary. ### Expected Behavior Scrolling to continue working. ### Actual Behavior The scrollbar is greyed out and I am no longer able to scroll using them or with the mouse wheel. On a FreeBSD remote system, I am also no longer able to select text sometimes, but at other times it works. With a Linux remote system, I have not seen this second behaviour. Switching back to the non-preview build that I have installed, 1.12.10983.0, appears to fix the issue. Happy to share a screen if that would help, feel free to ping me on Teams.
claunia added the Needs-TriageIssue-BugNeeds-Tag-FixProduct-Terminal labels 2026-01-31 05:47:37 +00:00
claunia commented 2026-01-31 05:47:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 31, 2022):

The scrollbar is greyed out

That sounds like they're using the alt buffer, which would be intentional...

@zadjii-msft commented on GitHub (May 31, 2022): > The scrollbar is greyed out That sounds like they're using the alt buffer, which would be intentional...
claunia commented 2026-01-31 05:47:38 +00:00
Author
Owner
Copy Link

@davidchisnall commented on GitHub (May 31, 2022):

I do not see this behaviour on any other terminal emulator (Konsole, xterm, or the macOS Terminal.app), or on older versions of the Windows Terminal, which leads me to believe that this is a bug.

@davidchisnall commented on GitHub (May 31, 2022): I do not see this behaviour on any other terminal emulator (Konsole, xterm, or the macOS Terminal.app), or on older versions of the Windows Terminal, which leads me to believe that this is a bug.
claunia commented 2026-01-31 05:47:38 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 31, 2022):

It definitely looks like they're using the alternate buffer. You can see the attach_session function calls client_setup_terminal, which selects the alternate buffer mode here:

8c32909a15/client.c (L51-L55)

I do not see this behaviour on any other terminal emulator (Konsole, xterm, or the macOS Terminal.app)

Some terminals still let you scroll back when in the alternate buffer, and some don't. I suspect those that support reflow on resize are less likely to allow it. But I'm surprised you can scroll back in Konsole, because the version I have definitely wasn't letting me scroll.

or on older versions of the Windows Terminal

Older version of Windows Terminal didn't support the alternate buffer at all, so that's why it might have appeared to work before.

@j4james commented on GitHub (May 31, 2022): It definitely looks like they're using the alternate buffer. You can see the [`attach_session`]( https://github.com/martanne/abduco/blob/8c32909a159aaa9484c82b71f05b7a73321eb491/abduco.c#L516) function calls [`client_setup_terminal`](https://github.com/martanne/abduco/blob/8c32909a159aaa9484c82b71f05b7a73321eb491/client.c#L35), which selects the alternate buffer mode here: https://github.com/martanne/abduco/blob/8c32909a159aaa9484c82b71f05b7a73321eb491/client.c#L51-L55 > I do not see this behaviour on any other terminal emulator (Konsole, xterm, or the macOS Terminal.app) Some terminals still let you scroll back when in the alternate buffer, and some don't. I suspect those that support reflow on resize are less likely to allow it. But I'm surprised you can scroll back in Konsole, because the version I have definitely wasn't letting me scroll. > or on older versions of the Windows Terminal Older version of Windows Terminal didn't support the alternate buffer at all, so that's why it might have appeared to work before.
claunia commented 2026-01-31 05:47:38 +00:00
Author
Owner
Copy Link

@davidchisnall commented on GitHub (Jun 1, 2022):

It looks as if the version of Konsole in the Debian repos no longer works with WSL1, so I can't try to reproduce that behaviour, but I was using Konsole with WSL and vcxsrv before I switched to Windows Terminal for daily use. I switched from tmux to abduco because I wanted to be able to use my terminal's scrolllback, rather than have something try to duplicate that functionality, and it worked fine with Konsole and continues to work today with Apple's Terminal.app.

It looks as if dtach doesn't use the alt screen, but it's annoying to have to switch to a third program (and install it on all of the systems that I regularly connect to) because of a change in the Windows Terminal behaviour, when abduco works correctly with every other terminal emulator that I use.

@davidchisnall commented on GitHub (Jun 1, 2022): It looks as if the version of Konsole in the Debian repos no longer works with WSL1, so I can't try to reproduce that behaviour, but I was using Konsole with WSL and vcxsrv before I switched to Windows Terminal for daily use. I switched from tmux to abduco because I wanted to be able to use my terminal's scrolllback, rather than have something try to duplicate that functionality, and it worked fine with Konsole and continues to work today with Apple's Terminal.app. It looks as if `dtach` doesn't use the alt screen, but it's annoying to have to switch to a third program (and install it on all of the systems that I regularly connect to) because of a change in the Windows Terminal behaviour, when `abduco` works correctly with every other terminal emulator that I use.
claunia commented 2026-01-31 05:47:38 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jun 2, 2022):

FYI, it looks like this is a know bug in abduco. See https://github.com/martanne/abduco/issues/35

And the suggested workaround is to execute printf '\033[?1049l' as the first thing in the session.

I'm curious how this is working for you in other terminals though. Because even if the terminal allowed you to scroll back in the alt buffer, all you would see is the content from before you started the abduco session. Any content that scrolled off screen when the alt buffer was active would still be lost. If that's not the case for you, then you must already be disabling the alt screen somehow.

@j4james commented on GitHub (Jun 2, 2022): FYI, it looks like this is a know bug in abduco. See https://github.com/martanne/abduco/issues/35 And the suggested workaround is to execute `printf '\033[?1049l'` as the first thing in the session. I'm curious how this is working for you in other terminals though. Because even if the terminal allowed you to scroll back in the alt buffer, all you would see is the content from before you started the abduco session. Any content that scrolled off screen when the alt buffer was active would still be lost. If that's not the case for you, then you must already be disabling the alt screen somehow.
claunia commented 2026-01-31 05:47:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 10, 2022):

Hmm. That is kinda weird that xterm lets you view the scrollback for the alt buffer. I was under the impression that was super non-standard. gnome-terminal certainly doesn't support that (and presumably the whole class of VTE emulators don't).

ESPECIALLY because the xterm docs themselves specifically say

The Alternate Screen Buffer

XTerm maintains two screen buffers. The Normal Screen Buffer allows you
to scroll back to view saved lines of output up to the maximum set by
the saveLines resource. The Alternate Screen Buffer is exactly as large
as the display, contains no additional saved lines. When the Alternate
Screen Buffer is active, you cannot scroll back to view saved lines.
XTerm provides control sequences and menu entries for switching between
the two.

This sounds like something abduco is gonna need to figure out on their end. Sorry you pivoted to another application just because we didn't support the alt buffer (https://github.com/microsoft/terminal/issues/381#issuecomment-634784208), only to have you pivot again now that we do 🙃

@zadjii-msft commented on GitHub (Jun 10, 2022): Hmm. That is kinda weird that xterm lets you view the scrollback for the alt buffer. I was under the impression that was super non-standard. `gnome-terminal` certainly doesn't support that (and presumably the whole class of VTE emulators don't). ESPECIALLY because the [xterm docs themselves](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-The-Alternate-Screen-Buffer) specifically say > ### The Alternate Screen Buffer > > XTerm maintains two screen buffers. The Normal Screen Buffer allows you > to scroll back to view saved lines of output up to the maximum set by > the [saveLines](https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:saveLines) resource. The Alternate Screen Buffer is exactly as large > as the display, contains no additional saved lines. When the Alternate > Screen Buffer is active, you cannot scroll back to view saved lines. > XTerm provides control sequences and menu entries for switching between > the two. > This sounds like something abduco is gonna need to figure out on their end. Sorry you pivoted to another application just because we didn't support the alt buffer (https://github.com/microsoft/terminal/issues/381#issuecomment-634784208), only to have you pivot again now that we do 🙃
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 Issue-Bug Needs-Tag-Fix Needs-Triage 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#17607
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?