Panes can be resized to zero and negative sizes

crides commented 9 months ago

What Operating System(s) are you seeing this problem on?

Linux X11, macOS

Which Wayland compositor or X11 Window manager(s) are you using?

awesome

WezTerm version

wezterm 20240102-011725-2f7ca41a

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

https://github.com/wez/wezterm/assets/15631555/3c4fba85-4ef8-4254-94f7-4136eb8d9fc3

This happens for columns as well, but it's less messy to show for rows

To Reproduce

It's shown in the video, but basically:

split down
go to the top pane, and split down
(in the middle pane now) split down again
drag the top most pane border So the tree structure is like:
```
+-+-+-- pane 1
| |       <-- drag this border
| +-+-- pane 2
|   |
|   +-- pane 3
|
+------ pane 4
```
pane 4 doesn't need to exist, it's there to show the effect

dragging the border between pane 2 & 3 for example, works correctly (produces only positive integer sizes)

Configuration

reproduces without any config

Expected Behavior

No response

Logs

No response

Anything else?

No response

crides commented 9 months ago

Okay the half is actually not a thing; wezterm stil renders the pane when the pane has 0 size (not the same as when the borders are overlapping, that would be size -1), and the border just happens to be (designed to be) at the half point

crides commented 9 months ago

I should also mention, that resizing with commands makes no difference

crides commented 9 months ago

Did some simple testing, and the last 3 commits of this branch seems to fix the issue. Probably not a good way to implement it though.

Basically 2 parts:

apply_pane_size doesn't propagate the size changes properly; adjust_x/y_size does, and using the latter to implement the former works
not sure why, but even given the above, the pane can still go to weird, seemingly negative sizes on screen (though in the pane tree the sizes say 1), so I just make adjust_node_at_cursor calculate the minimum sizes tree-wise as well

scauligi commented 2 months ago

This still happens on wezterm 20240203-110809-5046fc22, I'm running wezterm on macOS with AeroSpace (but still happens even with AeroSpace disabled).

wez / wezterm