Moving a WezTerm window between monitors causes erratic jumping and resizing of the window

[lsorber]

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

macOS

WezTerm version

20220512-142730-97f0bd16

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

I have noticed several distinct issues related to how the WezTerm window is rendered.

On an external monitor on macOS:

1. The window padding (set at a fixed 40px) is clearly larger on the external monitor compared to my laptop's display.
2. Moving the WezTerm window around with the mouse by dragging the tab bar causes the window to jump around.
3. Moving the WezTerm window close to the virtual boundary between my external monitor and laptop's display causes erratic resizing behaviour.

None of these issues occur on my MacBook Pro's display.

Video demonstrating these issues:

https://user-images.githubusercontent.com/4543654/168260141-1c5735f3-eed2-4a77-baa3-30c218469fc7.mp4

To Reproduce

1. Open a WezTerm window
2. Move the WezTerm window to an external monitor to observe issue (1)
3. Drag the WezTerm window around on the external monitor to observe issue (2)
4. Drag the WezTerm window to near the virtual boundary between the external monitor and the internal display to observe issue (3)

Configuration

local dracula = require 'dracula'; -- https://github.com/dracula/wezterm
local wezterm = require 'wezterm';

return {
  colors = dracula,
  font = wezterm.font("FiraCode Nerd Font", {weight="Medium"}),
  font_size = 16.0,
  initial_cols = 80,
  initial_rows = 24,
  show_tab_index_in_tab_bar = false,
  window_decorations = "RESIZE",
  window_frame = {
    font_size = 16.0,
    active_titlebar_bg = "#282a36",
    inactive_titlebar_bg = "#282a36",
  },
  window_padding = {
    left = "40px",
    right = "40px",
    top = "40px",
    bottom = "40px",
  },
  keys = {
    { key="LeftArrow",  mods="OPT", action=wezterm.action{SendString="\x1b\x62"} },
    { key="RightArrow", mods="OPT", action=wezterm.action{SendString="\x1b\x66"} },
    { key="LeftArrow",  mods="CMD", action=wezterm.action{SendString="\x01"} },
    { key="RightArrow", mods="CMD", action=wezterm.action{SendString="\x05"} },
    { key="z",          mods="CMD", action=wezterm.action{SendString="\x1f"} },
  },
}

Expected Behavior

1. That the window padding is the same size independent of the display or DPI
2. That the window doesn't jump around when dragging the window
3. That the window doesn't resize when dragging the window

Logs

I don't see any logs being generated when reproducing this issue.

Anything else?

No response

[cgraff]

Hello and good evening!

I can reproduce the issue easily (independently of internal / external monitor) on my MacBook Pro Display just by hiding the window decorations by setting the following config property:

config.window_decorations = 'RESIZE'

WezTerm Version

My current version is: wezterm 20230408-112425-69ae8472

MacOS Version

Ventura 13.3.1(a) (Apple Silicon)

[wez]

@cgraff please open a separate issue; this one is specific to having multiple monitors

[cgraff]

Hi @wez thanks for the hint. I think the problem went away after updating my Mac to MacOS 13.4. Cannot reproduce it anymore :-)

[thiagodiniz]

I have the same problem using with windows 11

[mikkelam]

I can confirm this as a problem on my 2560 x 1440 monitor. Changing resolution to half 1280 x 720 seems to resolve the issue (but other scale factors have similar issue for me)

[PiotrNawrot]

This is still an issue for me as well!

[nbelakovski-mssm]

I have this same problem, but I noticed that if I click and drag using the tab title, there's no jump. I opened up some more tabs and confirmed that clicking on any tab and dragging works as expected (it also selects that tab which is understandable). I tried clicking and dragging on the area without tabs while multiple tabs were open, in the hopes that maybe just having a second open tab could be a workaround, but it still jumps.

[gmckeown]

Also seeing this issue with WezTerm-20240203-110809-5046fc22 on Windows 11. I have different resolutions and scaling factors across three screens:

Left (3840x2160 at 200%) - Middle (1920x1200 at 125%) - Right (3840x2160 at 150%)

If I move the WezTerm window between the left and middle screens (either direction) it jitters around and resizes itself. If I move it between the middle and right screens, it works just fine. I did try setting the right screen to 200% scaling and it still works OK so I'm not sure what the difference is in moving to the left screen compared to the right screen!

As mentioned by @nbelakovski-mssm if I move using the tab bar instead of the title bar, the window moves without issue.

[NuclearDog]

I think I'm seeing this same behaviour.

The presumably relevant bit of my setup here is:

• Debian Trixie (Testing) running KDE + Wayland
• Top monitor is 2560x1440 @ 100% scaling; 75HZ
• Bottom monitor is 2560x1600 @ 125% scaling; 165HZ

Positioning wezterm on the top monitor and dragging down, I'm seeing:

• Dragging the window near the screen boundary never causes any issues.
• As soon as a pixel crosses the screen boundary, I get the erratic sizing behaviour.
• If I wiggle it around in that state for a while, it occasionally "breaks out" of it by resizing the window. Most often to a tiny postage-stamp sized thing. Sometimes to a size larger than the original.

I can never produce this behaviour dragging from the bottom screen to the top. I can wiggle the window around all over the boundary as long as I want and it works normally. As soon as the last pixel crosses onto the top screen though, the flickering starts.

Tried a few different configurations:

• Both screens at 100% scaling: No issue.
• Both screens at 125% scaling: No issue.
• Top at 125% and Bottom at 100% (Reverse): No erratic flickering, but the window does seem to change sizes a bit.
• Moved bottom screen to the left of the top: Same issue in the same direction (low -> high).
• Moved bottom screen to the right of the top: Same issue in the same direction (low -> high).
• Moved bottom screen above the top: No erratic flickering, but the window does seem to jump sizes a bit.

So at least in my case it seems to be an issue of moving from a screen with lower scaling to higher scaling, and for some reason it doesn't occur if the higher scaling screen is above the lower scaling.

Unfortunately I did all of this before remembering that Debian packages are usually ancient. So this is all as of a 202402-something build. I did try some of this again with the wezterm-nightly package (20250212-100137-9da362c7). More or less the same results. Differences I saw:

• It seems to pretty reliably only start the flickering after about half of the window is on the higher scaling monitor.
• When it decides to resize the window, instead of a postage stamp it now seems to end up 0px (no menu bar or anything, just the window borders left).
• It never resized bigger.

I did also try:

• Removing my config and running with the defaults and got the same behaviour.
• Enabling use_resize_increments. When the window goes to "zero", it looks like I'm getting a menu bar and 2x2 cells. As soon as the window loses focus, it goes to menu bar height + 1 cell.
• Enabling padding and specifying pixels, points, cells, or percent all results in the same "0px" behaviour as I was originally getting in nightly.
• I opened the debug overlay (Ctrl+Shift+L) and on replicating the "resize to zero" behaviour, got a notification "attempt to divide by zero" from termwiz/src/lineedit/mod.rs:202:21. Guessing that's more related to the debug overlay trying to calculate some sizes with a 0-sized terminal.
• window_decorations="TITLE" - slight flicker/resize when I hit the point where it normally starts freaking out, but that's it.
• Was having issues with NONE/etc, so set a window rule in KDE to forcefully disable the titlebar and frame. Got the same flicker as with TITLE, however it does occasionally resize to 0px. Still running, but the window's entirely gone.

Not sure how much further I can take this unless I sit down and learn Rust first so I enabled trace logging and recreated including the resize to zero. Lightly redacted log is here: wezterm-gui-log-95990.txt

That captures me:

1. Opening wezterm via a different terminal emulator; starting on the 100% scaling monitor.
2. Dragging it partially on to the 125% scaling monitor to where it starts resizing erratically
3. Waiting a moment for it to resize to zero.
4. Dropping it back on the 100% scaling monitor.
5. Switching back to the other terminal.
6. Hitting Ctrl+C to kill wezterm.

Hopefully some of that's helpful!

[NuclearDog]

Update: I can no longer reproduce this on 20251014-193657-64f2907c. I don't update consistently so I can't say where the fix was introduced.

@lsorber Do you still run into this issue on newer versions?

[m3Lith]

Update: I can no longer reproduce this on 20251014-193657-64f2907c. I don't update consistently so I can't say where the fix was introduced.

@lsorber Do you still run into this issue on newer versions?

The latest version is 20240203-110809-5046fc22, you mean you're using nightlies?