regression: xdg_toplevel_set_{min,max}_size on floating windows (since v0.54.0)

[Tom94]

(Related: #11723 (comment))

Since the v0.54.0 update, floating windows that have xdg_toplevel_set_{min,max}_size set seem to get resized back to their original size upon drag:

2026-03-03_16-27-47.mp4

If I unset the limits after the initial resize (to allow user resizing), they're lost entirely upon drag:

2026-03-03_16-37-35.mp4

Lastly, resizing via xdg_toplevel_set_{min,max}_size seems to no longer be centered. E.g. if I set the min size of my application to my monitor's dimensions, the full-screen floating window no longer covers the monitor exactly, but is offset slightly downwards.

[vaxerski]

can't repro on git. Can you provide a repro client?

[vaxerski]

I am running tev ./file and it doesnt seem to set the min/max size? yay -S tev I did

[Tom94]

Can you try opening a larger image, maybe? If you have 2x content scaling, the image I attached is too small to trigger a resize (fits into the default window size) -- I should have thought of this, sorry. https://wallhaven.cc/w/7j6xde

If it still doesn't set min/max, I'm very confused. Definitely hitting the breakpoint on my machine. (Possibly xwayland for some reason? If so, worth trying an appimage from here; I'm not maintaining the AUR package, so possibly misconfigured...)

EDIT: the behavior should match the second video from the OP

• app creates a regular window
• loads image
• sets xdg_toplevel_set_{min,max}_size to image size (possibly before first frame got rendered)
• calls wl_surface_commit
• sets xdg_toplevel_set_{min,max}_size back to 0 to allow user resizing
• idle

EDIT 2: probably unhelpful since it's the obvious place to look, but I bisected just in case and #12890 is the offending commit

EDIT 3: just in case it matters, windowrule = match:class ^(tev)$, float on is how I configured floating in the OP

[vaxerski]

no.tev.bug.mp4

[vaxerski]

wl debug shows multiple instances of

[3916334.386] {Default Queue}  -> xdg_toplevel#45.set_min_size(0, 0)
[3916334.388] {Default Queue}  -> xdg_toplevel#45.set_max_size(0, 0)

[Tom94]

Anything change if you add --no-maximize? Otherwise out of ideas :/

EDIT: nevermind. I set up a clean Archlinux container, ran yay -S tev like you did, and was still able to reproduce. I am drawing blanks about what aspect of your environment could cause the reproduction failure. Hopefully my other comment w/ debug logs can help narrow this problem down.

[Tom94]

Here's a simpler setup w/ debug log that'll hopefully make it easier to figure out what's going on:

• app starts with default size of 1024x800
• sets xdg_toplevel_set_{min,max}_size to 711x800 once and then never again (log line 4395)
  • note that it is important that this happens after the app got initialized. If the xdg_toplevel_set_{min,max}_size calls happen early enough (e.g. before surface enter and fractional scale messages), the bug goes away
• gets conflicting xdg_toplevel.configure callbacks (1024x800 on drag and to 711x800 whenever drag stops)

Config:

debug {
	disable_logs = false
	enable_stdout_logs = true
}

windowrule = match:class ^(tev)$, float on
bindm = ALT, mouse:272, movewindow
exec-once = tev ~/Tresorit/Sync/projects/2017-tev/test-images/png/revoy-cICP-bt.2020.png

Exec:

WAYLAND_DEBUG=1 ../Hyprland/build/Hyprland --config ~/.config/hypr/minimal.conf > hypr9.log 2>&1

Video:

2026-03-04_07-04-52.mp4

[tekstryder]

I ran into this by accident about a week ago.

Forgot to bisect tho.

Had size specified for gnome-calculator, overriding/overextending its allocated bounds:

windowrule = float on, center on, size 400 600, match:class org.gnome.Calculator

screencast-2026-03-04_08-41-31.mp4

Window 557aeb732dc0 -> Calculator:
	mapped: 1
	hidden: 0
	at: 1926,390
	size: 360,616
	workspace: 1 (1)
	floating: 1
	monitor: 1
	class: org.gnome.Calculator

[tekstryder]

Bisected with old builds down to this range 8b17a74...b88813c.

Of course that contains rethonk. I can finish the bisect if you'd like.

EDIT: He could not, in fact, finish the bisect.

Something odd with building those old commits on current stack results in a frozen session at start. Not willing to troubleshoot that rabbit hole further.

Vaxry should be able to tell with that small commit range which is the culprit.

[tekstryder]

To be clear, 8b17a74 was last good commit of the builds I still have on hand.

@Tom94 maybe you could finish the bisect from there? Just 10 commits to go.

[Tom94]

Already bisected to rethonk being the culprit -- mentioned in the first back and forth with vaxry.

Being on nix helped with automatically getting working dependencies at each commit. :p

[tekstryder]

Already bisected to rethonk

Ah, I missed ur edit.

I didn't look into the build issue further, but nothing in the stack really changed in the past few weeks. But, I'll give nix the W there haha.

[the-nummer-zone]

https://github.com/user-attachments/assets/6ce87e9e-13a3-482e-9bec-44a6e967aa70
sysinfo.txt
log.txt

here's what i provided when i opened a different discussion regarding this bug before being directed here, hopefully there's something of note here :P

[tekstryder]

Happens on modals too:

screencast-2026-03-07_14-44-29.mp4

[the-nummer-zone]

i've seen that too (e.g. audacity save prompt)

[tjb0607]

happening for me too, specifically that hyprland doesn't seem to properly keep track of when a floating xwayland client changes its own size. when moving/resizing the window, the size jumps back to whatever hyprland set it to last, which can be out-of-date:

2026-03-07.23-54-37.mp4

[tekstryder]

hyprland doesn't seem to properly keep track of when a floating xwayland client changes

No Xwayland (-DNO_XWAYLAND:STRING=true) here, so that's not specific to the issue.

Still easy to repro on v0.55.0 release with simple gnome-calculator and window rule as described in #13539 (comment):

hl.window_rule({ match = { class = "org.gnome.Calculator" }, float = true, center = true, size = "400 600" })

and with modals as described in #13539 (comment):

screencast-2026-05-09_13-12-12.mp4

[tjb0607]

This can also be reproduced by downloading the RuneLite AppImage from here: https://runelite.net/

You do not need to log in, the issue can happen from the title screen.

1. make the window floating
2. resize the window to as small as it can get
3. use the icons on the right-hand side to expand the sidebar
4. move the window and its size will glitch as if you hadn't expanded the sidebar
5. resize the window so that you can actually access the sidebar again
6. hide the sidebar
7. move or resize the window and its size will glitch as if you hadn't closed the sidebar

2026-05-10.15-57-08-handbrake.mp4

[swomf]

This also causes behavior with jtheoof/swappy especially since its max/min can change during the app runtime. It's not just drag; hl.dsp.window.move is also affected.

Hyprland 0.55.4 built from branch v0.55.4 at commit a0136d8c04687bb36eb8a28eb9d1ff92aea99704 clean ([gha] Nix: update inputs).
Date: Thu Jun 11 17:10:04 2026
Tag: v0.55.4, commits: 7378

Libraries:
Hyprgraphics: built against 0.5.1, system has 0.5.1
Hyprutils: built against 0.13.1, system has 0.13.1
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.12.1, system has 0.12.1

Version ABI string: a0136d8c04687bb36eb8a28eb9d1ff92aea99704_aq_0.12_hu_0.13_hg_0.5_hc_0.1_hlg_0.6
no flags were set

recording.mp4

[tekstryder]

This issue is fixed at long last by commit 8149ba1.

• desktop/view: sync layout's m_box in clampWindowSize #15266

I can no longer repro either #13539 (comment) nor #13539 (comment).

[tekstryder]

@Tom94 if you're still around and using Hyprland, please test and mark this discussion as answered.