New tabs only occupy a fraction of the pane

[SpyrosRoum]

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

Linux X11

WezTerm version

wezterm 20210823-215916-fc441e98

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

Some extra info: I am using dwm
The bug: When starting wezterm if I don't resize it, the first tab is fine, but if I open a second, third, etc tab it only occupies the top left. If at any point I resize it, all tabs are good.
The reason I mentioned my WM is that if I use the floating layout and open wezterm, the wezterm window takes up the space that new tabs take, so it's like new tabs thing wezterm only has as much space as it would have if it had spawned floating.

To Reproduce

(Possibly need a tilling WM/dwm)
Start wezterm
Open a new tab (without resizing the window)
Run something like htop/vim/or just enough commands to see that it doesn't take up the whole window

Configuration

no config

Expected Behavior

For the new tabs to take up the whole window

Logs

2021-08-24T08:54:15.676Z INFO wezterm_mux_server_impl::local > setting up /run/user/1000/wezterm/gui-sock-39286
2021-08-24T08:54:15.757Z INFO wezterm_gui::termwindow > OpenGL initialized! AMD Radeon RX 6800 (SIENNA_CICHLID, DRM 3.41.0, 5.13.12-zen1-1-zen, LLVM 12.0.1) 4.6 (Compatibility Profile) Mesa 21.2.1 is_context_loss_possible=false wezterm version: 20210823-215916-fc441e98

Anything else?

[wez]

Please start wezterm like this: WEZTERM_LOG=wezterm_gui::termwindow::resize=trace,info wezterm, reproduce the issue and add the stderr output here. That will show us information about the resize and help to understand what is happening.

[SpyrosRoum]

Here is the output. All of it got printed at the start, I tried opening a couple new tabs but there was no new output

 2021-08-24T15:56:00.940Z INFO  wezterm_mux_server_impl::local > setting up /run/user/1000/wezterm/gui-sock-159899
 2021-08-24T15:56:01.046Z TRACE wezterm_gui::termwindow::resize > resize event, current cells: RowsAndCols { rows: 24, cols: 80 }, new dims: Dimensions { pixel_width: 1396, pixel_height: 1407, dpi: 96 } window_state:(empty)
 2021-08-24T15:56:01.046Z TRACE wezterm_gui::termwindow::resize > apply_dimensions Dimensions { pixel_width: 1396, pixel_height: 1407, dpi: 96 } scale_changed_cells None. window_state (empty)
 2021-08-24T15:56:01.046Z TRACE wezterm_gui::termwindow::resize > apply_dimensions computed size PtySize { rows: 62, cols: 139, pixel_width: 1390, pixel_height: 1364 }, dims Dimensions { pixel_width: 1396, pixel_height: 1407, dpi: 96 }
 2021-08-24T15:56:01.051Z INFO  wezterm_gui::termwindow         > OpenGL initialized! AMD Radeon RX 6800 (SIENNA_CICHLID, DRM 3.41.0, 5.13.12-zen1-1-zen, LLVM 12.0.1) 4.6 (Compatibility Profile) Mesa 21.2.1 is_context_loss_possible=false wezterm version: 20210823-215916-fc441e98

[MuhammedZakir]

This happened after the fix for #695 (2 weeks ago).

#695 (comment):

After this fix, in tiling mode, initial size of a new tab created using Ctrl+Shift+T is 80x24. Floating and tiling it again, or resizing the window fixes this. After doing this once, newly created tabs for that window get correct/current size.

[wez]

I've pushed a speculative fix for this in 41866a0
Please give the nightly build a try; binaries should be updated within 30 minutes of this comment, or you can build from source directly if you prefer.

[SpyrosRoum]

Hm no the issue still exists but I stumbled onto something (maybe?)
Basically I completely forgot about this because something in my config might have fixed it (not sure if that's even possible)
When I run wezterm -n start I have the issue, when I don't use the -n flag I don't have the issue and that's happening every time I tried.
Here is my config if it helps

Edit: This info applies for both the version in the arch repos and the latest git

[SpyrosRoum]

Ah wait, my bad. I pulled the latest version but I didn't compile it
The issue is indeed fixed in nightly, sorry for the false information

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.