Wezterm creates crazy large window on Wayland in Fedora 40

[nbenitez]

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

Linux Wayland

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

Mutter: default in Fedora 40

WezTerm version

wezterm 20240429_102818_0184e88e (Using Copr repo)

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 just installed Fedora 40, installed Wezterm from Copr repo so it must be latest version, and when launching Wezterm it displays a very large window (goes further off-screen) and within it the terminal window only occupies a quarter of it, please check out the screenshots I attached below.

My display configuration, which wezterm correctly reports in wezterm.gui.screens(), (attached below) is, an external HiDPI monitor 3840x2160 at scale 2 connected to my laptop, the laptop screen is always off (set as inactive in Gnome display settings), so it's correct that it does not appear in wezterm.gui.screens() output.

To Reproduce

Just launch Wezterm from desktop file or from a terminal i.e. wezterm start --cwd . on a Fedora 40 Wayland session.

Configuration

-- I think the Bug is not affected by a specific configuration, but nonetheless I'm pasting mine below:
config.window_decorations = "RESIZE"
config.enable_wayland = true;
config.enable_tab_bar = false
config.scrollback_lines = 10000 -- default is 3500
config.hide_mouse_cursor_when_typing = false
config.pane_focus_follows_mouse = true
config.check_for_updates = false
config.font_size = 10.0
config.adjust_window_size_when_changing_font_size = false
-- no ligatures
config.harfbuzz_features = {"calt=0", "clig=0", "liga=0"}

Expected Behavior

The terminal window (i.e. black terminals as shown in the screenshot) should occupy all the window not just a quarter of it, and the window itself should have a normal size, not a width that goes far far right off-screen.

I think my setup it's pretty normal on Linux i.e. latest Fedora in a laptop connected to an external monitor.

Logs

Debug Overlay
wezterm version: 20240429_102818_0184e88e x86_64-unknown-linux-gnu
Window Environment: Wayland
Lua Version: Lua 5.4
OpenGL: Mesa Intel(R) HD Graphics 530 (SKL GT2) 4.6 (Compatibility Profile) Mesa 24.0.5
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
> wezterm.gui.screens()
{
"active": {
"effective_dpi": 192,
"height": 2160,
"name": "DP-2",
"scale": 2,
"width": 3840,
"x": 0,
"y": 0,
},
"by_name": {
"DP-2": {
"effective_dpi": 192,
"height": 2160,
"name": "DP-2",
"scale": 2,
"width": 3840,
"x": 0,
"y": 0,
},
},
"main": {
"effective_dpi": 192,
"height": 2160,
"name": "DP-2",
"scale": 2,
"width": 3840,
"x": 0,
"y": 0,
},
"origin_x": 0,
"origin_y": 0,
"virtual_height": 2160,
"virtual_width": 3840,
}

Anything else?

[osandov]

I'm seeing this, too. Removing window_decorations = 'RESIZE' from my config seems to have fixed it, although I am still getting a bunch of ERROR window::os::wayland::window > set_cursor: Cursor not found log lines that weren't there before Fedora 40.

[nbenitez]

I confirm it seems related to window_decorations = 'RESIZE'.

More oddities, if I remove window_decorations="RESIZE" then window:gui_window():maximize() on gui-startup event is not obeyed.

Definitively the combinations of window_decorations options with maximize() need be tested with latest Wayland on latest GNOME/Fedora.

[wez]

Please try the most recent nightly build

[nbenitez]

I just did, unfortunately the bug is still there.

[osandov]

I built the main branch from source and still have the bug on my scaled laptop display, too.

[RomanAverin]

Visually nothing has changed except for the panic.

[abhinavgaba]

I have the same issue with the latest build (wezterm 20240520_084532_da2d0ad2) on Fedora 40 + gnome.

[Aokigahara23]

same here 😢

Fedora 40
Plasma 6.0.5
wezterm 20240617-083535-cb140686

UPD: just got the plasma 6.1.0 update - problem remains

[ShadowRZ]

Same problem here.

When WezTerm starts, by default it should spawn a window with the character cell dimension of 80x24, however with either of the window_decorations='RESIZE' or window_decorations='INTEGRATED_BUTTONS' config option, the same problem happened, and using the tput command to query the terminal size gives this:

$ tput lines
50
$ tput cols
162

The terminal size is almost doubled.

Also appeareantly, on my machine WezTerm would double its window size randomly for no good reason, eventually panics with Viewport dimensions are too large. However the actual terminal content still only occupies a quarter of the window content.

wezterm 20240624-065522-552bb1d6 (AppImage)
Plasma 6.1.1 on KWin Wayland

[dani162]

For me, the size of the window frame doubles every time I tab to another program and then back to wez term.
This only happens when the terminal uses client-side decorations (Fedora GNOME 46, config.window_decorations = “RESIZE”) and is on my monitor with 150% scaling fractional (3840x2160).
On the other monitor (100% scaling, 1920x1080) this does not occur.

Tests with local build from main.

Here some Logging that i added to my local build for debugging:

[dani162]

Changing the window frame height and width to the surface width (let w) and height (let h) seems to apply the correct size to the window, but the window is still slightly increasing the size on focus and losing focus.

diff --git a/window/src/os/wayland/window.rs b/window/src/os/wayland/window.rs
index 74ba5ae6b..69362de12 100644
--- a/window/src/os/wayland/window.rs
+++ b/window/src/os/wayland/window.rs
@@ -841,10 +841,8 @@ impl WaylandWindowInner {
                 log::trace!("Resizing frame");
                 if !self.window_frame.is_hidden() {
                     // Clamp the size to at least one pixel.
-                    let width =
-                        NonZeroU32::new(pixel_width as u32).unwrap_or(NonZeroU32::new(1).unwrap());
-                    let height =
-                        NonZeroU32::new(pixel_height as u32).unwrap_or(NonZeroU32::new(1).unwrap());
+                    let width = NonZeroU32::new(w).unwrap_or(NonZeroU32::new(1).unwrap());
+                    let height = NonZeroU32::new(h).unwrap_or(NonZeroU32::new(1).unwrap());
                     self.window_frame.resize(width, height);
                 }
                 let (x, y) = self.window_frame.location();

[dani162]

@aliaksandr-trush could the resizing on focus change be related to #6262?

[aliaksandr-trush]

@aliaksandr-trush could the resizing on focus change be related to #6262?

I do not think so.
I would say Window Frame calculation logic should be reviewed. I've already made some changes to it #5971 but looks like additional changes required like review dpi scaling factor.