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

Wrapping over multiple lines in a single write fails in conhost #21797

New Issue
Closed
opened 2026-01-31 07:55:09 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 07:55:09 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Jun 1, 2024).

Windows Terminal version

Commit 4a243f0445

Windows build number

10.0.19045.4412

Other Software

No response

Steps to reproduce

  1. Open a bash shell in a recent build of OpenConsole.
  2. Make sure you have some scrollback enabled.
  3. Set the width to 80 columns
  4. Execute the following statement: 
    printf "\e[2J\e[999;70HFirst line Second line                                                                     Third line\e[H"

Expected Behavior

That should output a string a text wrapping over three lines, starting at the bottom of the page, so the viewport scrolls up by two rows. It should look something like this:

image

Actual Behavior

The third line doesn't scroll the viewport, but instead wraps up onto the previous line (i.e. the first line), ending up like this:

image

This was a regression caused by PR #16615. The problem is that we're reusing the same Page object in multiple _DoLineFeed calls, but when a scroll is triggered (specifically one that pans the viewport), the viewport coordinates stored in the Page object are no longer correct. I'm working on a PR to fix this.

Note that this doesn't appear to affect Windows Terminal, because it doesn't have any scrollback in conhost, so the viewport doesn't move.

Originally created by @j4james on GitHub (Jun 1, 2024). ### Windows Terminal version Commit 4a243f044572146e18e0051badb1b5b3f3c28ac8 ### Windows build number 10.0.19045.4412 ### Other Software _No response_ ### Steps to reproduce 1. Open a bash shell in a recent build of OpenConsole. 2. Make sure you have some scrollback enabled. 3. Set the width to 80 columns 4. Execute the following statement: ``` printf "\e[2J\e[999;70HFirst line Second line Third line\e[H" ``` ### Expected Behavior That should output a string a text wrapping over three lines, starting at the bottom of the page, so the viewport scrolls up by two rows. It should look something like this: ![image](https://github.com/microsoft/terminal/assets/4181424/fdc0b8c1-e386-4485-8259-e8600b544a44) ### Actual Behavior The third line doesn't scroll the viewport, but instead wraps up onto the previous line (i.e. the first line), ending up like this: ![image](https://github.com/microsoft/terminal/assets/4181424/b4b341b7-5fbb-4792-9b6b-8143ffb02f5a) This was a regression caused by PR #16615. The problem is that we're reusing the same `Page` object in multiple `_DoLineFeed` calls, but when a scroll is triggered (specifically one that pans the viewport), the viewport coordinates stored in the `Page` object are no longer correct. I'm working on a PR to fix this. Note that this doesn't appear to affect Windows Terminal, because it doesn't have any scrollback in conhost, so the viewport doesn't move.
claunia added the Needs-TriageIssue-Bug labels 2026-01-31 07:55:10 +00:00
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-Triage
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#21797
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?