Windows Terminal version
1.24.11911.0 (stable), also 1.25.1912.0 (Preview), and a local Dev build of current main
Windows build number
10.0.26200.9168
Other Software
Reproduced with ordinary PowerShell / cmd panes (no special client). Machine: Intel Core Ultra 5 225H, 32 GB RAM.
I already have a fix and will send a PR against this issue.
Steps to reproduce
- Open Windows Terminal (stable is enough; Debug Dev builds make it much worse).
- Split the tab into 4 panes (
Alt+Shift++ / Alt+Shift+-).
- Focus a pane and hold
Alt+Shift+Left or Alt+Shift+Right for a couple of seconds.
- Repeat while the terminals have a typical amount of scrollback / output.
Expected Behavior
The splitter should keep moving while the key is held, and the window should stay responsive. Releasing the key should stop the splitter immediately.
Actual Behavior
Keyboard auto-repeat is ~30 Hz. Each resizePane currently calls _CreateRowColDefinitions() immediately, which forces a XAML grid relayout and a reflow of every terminal under that splitter.
With 4 panes that work costs more than one key-repeat period, so auto-repeat queues more layouts than the UI thread can finish:
- the splitter hitch-steps (stalls a few frames, then jumps)
- occasionally one apply lands after a UI stall and the splitter jumps half the window
- in the worst case the window stops pumping messages and has to be killed (ANR)
Stable is already visibly janky. A Debug Dev build makes it easy to freeze the window entirely.
Before (stable / unpatched, 4 panes, hold Alt+Shift+Left/Right):
After (same repro on a local build of the upcoming PR): layout applies are rate-limited to recent UI cost (32–250 ms), at most one in-flight apply, and each apply is capped to a 10% split delta so a stall cannot jump half the screen.
Related but different: #19996 (hang at 1-cell width with a double-width glyph — a reflow crash, not this queueing problem). #19490 sounded similar (freeze while expanding a pane) but closed without a repro.
Windows Terminal version
1.24.11911.0 (stable), also 1.25.1912.0 (Preview), and a local Dev build of current
mainWindows build number
10.0.26200.9168
Other Software
Reproduced with ordinary PowerShell / cmd panes (no special client). Machine: Intel Core Ultra 5 225H, 32 GB RAM.
I already have a fix and will send a PR against this issue.
Steps to reproduce
Alt+Shift++/Alt+Shift+-).Alt+Shift+LeftorAlt+Shift+Rightfor a couple of seconds.Expected Behavior
The splitter should keep moving while the key is held, and the window should stay responsive. Releasing the key should stop the splitter immediately.
Actual Behavior
Keyboard auto-repeat is ~30 Hz. Each
resizePanecurrently calls_CreateRowColDefinitions()immediately, which forces a XAML grid relayout and a reflow of every terminal under that splitter.With 4 panes that work costs more than one key-repeat period, so auto-repeat queues more layouts than the UI thread can finish:
Stable is already visibly janky. A Debug Dev build makes it easy to freeze the window entirely.
Before (stable / unpatched, 4 panes, hold
Alt+Shift+Left/Right):After (same repro on a local build of the upcoming PR): layout applies are rate-limited to recent UI cost (32–250 ms), at most one in-flight apply, and each apply is capped to a 10% split delta so a stall cannot jump half the screen.
Related but different: #19996 (hang at 1-cell width with a double-width glyph — a reflow crash, not this queueing problem). #19490 sounded similar (freeze while expanding a pane) but closed without a repro.