Mux doesn't recognize window size in tiling environments

[seqizz]

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

Linux X11

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

awesomewm 4.3

WezTerm version

Compiled from commit 119c2f1

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

No, and I'll explain why below

Describe the bug

Tried to switch to mux, but apparently it's not correctly evaluating window size on startup.

This is not the case if I start a normal terminal with wezterm start --class mainqterm command. It happens when I run wezterm connect default --class mainqterm command.

I tried to do some hacks but couldn't change the main behavior: It starts like this and only corrects itself once I resize the window, or reload the configuration.

To Reproduce

I guess you'd need an environment with window rules defined & enforce maximizing of the Wezterm windows on start

Configuration

  -- multiplexing stuff
  unix_domains = {
    {
      name = "default",
      socket_path = "/home/gurkan/.wezterm.sock",
      connect_automatically = false,
    }
  },
  mux_env_remove = {
    "SSH_CLIENT",
    "SSH_CONNECTION",
  },

Expected Behavior

Similar behavior for the non-mux window, initial row/col count matching the initial window size.

Logs

~> wezterm connect default --class mainqterm
12:25:43.902  ERROR  wezterm_gui::termwindow > new_window has no tabs... yet?
12:25:44.353  WARN   wezterm_client::client  > While connecting to Socket("/home/gurkan/.wezterm.sock"): connecting to /home/gurkan/.wezterm.sock.  Will try spawning the server.
12:25:44.353  WARN   wezterm_client::client  > Running: "/nix/store/qvnjmpm28fbj31648j7c4dd5aj5jpngc-wezterm/bin/wezterm-mux-server" "--daemonize"

Anything else?

Relevant discussion item: #2311 (comment)

[wez]

Related issues:

• mux server crash w/ multiple clients with different window sizes #2133
• (slightly less so:) When using domain sockets, terminal inside pane doesn't get resized. #2270

[wez]

The behavior has been improved in main; give it a try and let me know how well it works for you?

[seqizz]

Now compiled from ef532fc, but couldn't see anything different.

Checking the change, it feels like adding a new tab should do it, but sadly it didn't. Here is an example split inside new tab:

Tried getting debug log but couldn't see anything shiny in it, I could provide some trace if it could help.

[cpence]

Hate to just give a plain +1, but if there's any kind of log or data collection I could offer, I have exactly the same bug. Wezterm 20221119-145034-49b9839f.

Resize behavior is perfect if I use wezterm connect local and stuck at 80x24 (until I do a floating/tiled or fullscreen/non-fullscreen toggle) if I use wezterm connect unix.

[wez]

Would you mind trying the latest nightly build and let me know whether this is resolved?

[seqizz]

Sadly it is same.

(from alacritty): running wezterm-mux-server with following in the wezterm config:

  unix_domains = {
    {
      name = "default",
      socket_path = "/home/gurkan/.wezterm.sock",
      connect_automatically = false,
    }
  },

After it starts, running wezterm connect default --class mainqterm says:

14:30:13.563  ERROR  wezterm_gui::termwindow > new_window has no tabs... yet?
14:30:13.828  WARN   window::os::x11::connection > Unable to resolve appearance using xdg-desktop-portal: Reading xdg-portal org.freedesktop.appearance color-scheme: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files

Then opens a window like this, unless I resize it confines terminal in lesser area:

[wez]

It's possible that 8dd365d may help here

[seqizz]

Thanks. It looks like it helped 🚀
But I reproduced same issue on 2nd try by chance. E.g.:

• Run wezterm-mux-server on one terminal
• Run wezterm connect default --class mainqterm on another terminal:
• Wezterm starts, with normal size, no issues. Even closing the window and re-running same command lands you into same environment as expected.
• Logout from the open terminal (e.g. Ctrl-D)
• Re-run the connect command (to get a new session from mux server)
• New terminal is half-sized again

[wez]

8f74e1c fixes some cache invalidation issues around resizing, not sure that it will help here, but I thought it was worth a mention.

[seqizz]

Thanks for the reminder. I wasn't using the nightly for a while, and already testing the flake from #4843 (which doesn't even cover the commit you mentioned, forked over 12a6b8d).
But I can't reproduce this issue anymore, connected client is always covering the all available area even after multiple runs. So feel free to close 🚀

[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.