Some panes stop resizing after other panes are closed

[valorin]

There appears to be an issue caused by animations when panes are closed. With animations enabled and multiple panes (3+) in use, when you close a panel and attempt to resize the remaining panes, some of the panes don't resize correctly. I haven't tested extensively, however it appears that the created panes are the ones that cannot resize, while the original pane does get resized.

This is on the new Preview that was released today.

UPDATE: This doesn't appear to require animations enabled. I've experienced it with animations disabled when moving around and closing panes. It seems to be triggered first by removing a pane, as everything works as expected until I close something. After that point, the behaviour is weird and some panes stop resizing.

I'll leave the steps below as-is, as that's the most reliable way to replicate that I've discovered.

Environment

Windows build number: 10.0.19041.0
Windows Terminal version: Preview 1.5.3142.0

Steps to reproduce

1. Ensure animations are enabled in the config ("disableAnimations": false),
2. Split the terminal into three panes. I've been using a vertical then a horizontal split:

   { "command": { "action": "wt", "commandline": "split-pane -V ; split-pane -H" }, "keys": "ctrl+alt+shift+l" },
   

3. Close the second panel. For me this is top-right. The third pane correctly resizes to fill the gap left from the closed panel.
4. Resize the remaining pane divider

Expected behavior

The pane divider should resize, with both panes included.

Actual behavior

The first pane is resized, but the second (originally the third) stays where it is. As a result, you either have a gray gap between the two panes, or the first pane covers up the second pane.

Toggling "disableAnimations": true to disable animations fixes the issue and the panes resize correctly.

3 panes showing top before the second pane is closed

Remaining two panes showing the second pane no resizing with the the first:

[Don-Vito]

@valorin - for me the problem occurs only when animations are enabled. Could not reproduce it with animations disabled.
[Update] - was able to reproduce it without animations, but in more complex scenario.

[valorin]

Yeah that's exactly what happened with me. It's simple with animations, but harder and more random without them.

[Don-Vito]

BTW, it looks that disabling animation applies only to the "close pane" animation, but not to pane entrance animation.
@zadjii-msft - is it intentional?

[zadjii-msft]

@Don-Vito It most certainly is not

[Don-Vito]

@Don-Vito It most certainly is not

NP. I am creating a PR to allow disabling 😊

[Don-Vito]

In any case with animations fully disabled (both close and entrance), I am currently unable to reproduce the issue.. of course probably the issue is somewhere else and animations just increase the probability.