DTTERM window manipulation shrinks the window even though it requests the current size #23579

Open
opened 2026-01-31 08:46:19 +00:00 by claunia · 1 comment
Owner

Originally created by @grawity on GitHub (Sep 2, 2025).

Windows Terminal version

1.23.12371.0

Windows build number

10.0.26100.5074

Other Software

OpenSSH_for_Windows_9.5p2
Neovim NVIM v0.11.4 (on Arch Linux)

Steps to reproduce

Maximize the Windows Terminal window.
ssh to some Linux system.
Run nvim (maybe nvim --clean).
Ctrl-Z suspend Nvim and return to the shell.
fg resume Nvim.

Expected Behavior

The terminal window should remain maximized.

Actual Behavior

The terminal window shrinks in height by 1 row every time fg returns to Nvim.

Originally created by @grawity on GitHub (Sep 2, 2025). ### Windows Terminal version 1.23.12371.0 ### Windows build number 10.0.26100.5074 ### Other Software OpenSSH_for_Windows_9.5p2 Neovim NVIM v0.11.4 (on Arch Linux) ### Steps to reproduce Maximize the Windows Terminal window. `ssh` to some Linux system. Run `nvim` (maybe `nvim --clean`). Ctrl-Z suspend Nvim and return to the shell. `fg` resume Nvim. ### Expected Behavior The terminal window should remain maximized. ### Actual Behavior The terminal window shrinks in height by 1 row every time `fg` returns to Nvim.
claunia added the Issue-BugPriority-3Area-VTProduct-Terminal labels 2026-01-31 08:46:20 +00:00
Author
Owner

@DHowett commented on GitHub (Sep 10, 2025):

Alright, I got this under a debug tap. It looks like nvim is trying to restore the window to the size it was in before it was suspended:

Image

I wonder if this is the same root cause as the cluster of issues around #18862 #18582 #18872 (maybe #19265 - if we are doing the math based on the wrong profile) where we receive one of these, calculate the wrong final size, and resize to be slightly smaller than expected.

Three potential fixes. Maybe we should do all of them.

  • throw out any OSC 8 ; Ps ; Ps t where both Ps match the current size
    • honestly we should never let this escape the terminal layer; it's a lot of work for a no-op
  • allow users to disable window manipulation
  • actually fix the bug in the math 😜
@DHowett commented on GitHub (Sep 10, 2025): Alright, I got this under a debug tap. It looks like nvim is trying to restore the window to the size it was in before it was suspended: <img width="878" height="463" alt="Image" src="https://github.com/user-attachments/assets/3902754e-c8ab-452d-a3d3-435ca9ca95f7" /> I wonder if this is the same root cause as the cluster of issues around #18862 #18582 #18872 (maybe #19265 - if we are doing the math based on the wrong profile) where we receive one of these, calculate the wrong final size, and resize to be slightly smaller than expected. Three potential fixes. Maybe we should do all of them. - throw out any `OSC 8 ; Ps ; Ps t` where both `Ps` match the current size - honestly we should never let this escape the terminal layer; it's a lot of work for a no-op - allow users to disable window manipulation - actually fix the bug in the math 😜
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23579