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.

[Don-Vito]

@zadjii-msft - I think I have a direction here 😊 This is a race. If you split the panes manually and slowly (aka after the animation has finished) no problem occurs.

My guess is that in the completion of the animation, when you access the pane, it already has other children.

I fixed it locally and it seems to work (although this is a race and you can never know 😊). Creating the PR for this one as well

[Don-Vito]

@zadjii-msft - actually I am not sure what is the best fix. What I am doing in PR is to ensure that the correct control gets the stretch alignment back.

However the problem is more severe: during the animation the pane children might change. This applies not just for entrance animation but for the close animation as well. I am not sure what should be the approach - to lock the panes during the animation?

[Don-Vito]

Related to #7942

[zadjii-msft]

You know, locking the panes during the animation sounds like a really good idea, one that would probably resolve a whole host of these issues.

[ghost]

🎉This issue was addressed in #8241, which has now been successfully released as Windows Terminal v1.5.10271.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #8241, which has now been successfully released as Windows Terminal Preview v1.6.10272.0.:tada:

Handy links:

• Release Notes
• Store Download