All programs launch already maximised since update

[non-bin]

Hyprland version

v0.56.0 (52b368f)

Is this a regression?

Yes, worked in 5751911, broken by af0d014

Bisection:

52b368f1d7fdee1b0e96ef3dc655b5a577df4fdb Bad
9d4f7a83ce2764ddb51b4ea01f8ae1e6f1c18f66
0e737901cd4f206d4abed0bcf5cfee4cdd6c23b9
af0d014cb26f536d8cb7cab2b9d5784f69767c8a Bad
5751911091d2bbcd580597d489a1ec0b9dd542bd Good
a1b9dc0e8cdfeca3e2d96a24b10b3d85e14fbd50 Good
fea3b3367b0990cf8f559e7bf3f71e98f6ca722b
a0c6946d667cca640f8bb459aabfc37aa8343176 Good
6d43ce8453f2d34b82b3da5ed9415f6fc3046ce4
153df31d2c9f2d366f4aa035db4946cbac2b3729
ab2d313b551f004878ada2bbb30c67bb674822f5
1256bd180e7677aadd715e59351c09fb16e48efc Good
24e23ca4bb6041014c3b784fdf5012b2fdae89ac
a269fd77b00cd27ea8f74f315f887bc30ffd7b92
0cef51ab7219c27ab0e06cf9de75ed5faaebfeee
8a24bb3bb6100fb2c1fe31991036dd57dc7723c1
45c8510c9c52aee541ac2b31c2b716d61c526241
58c22e7af4cdafc705fc4ef9ef37cf7a0a9e5d80
814603164eef4772fe5c8878358fed7fde261ee1
b5a6d81f473d5b3318ed8ae305f8c2de71faf9a6 Good

What's the bug?

Every program I launch is automatically maximised, except for ghostty +new-window because the daemon launches it, if I just run ghostty it is maximised. I bisected it to #15779

Reproduction steps

NixOS 26.11 (Unstable 2026-08-20 7f4c783)

-- hyprland.lua

-- Generated by Home Manager.
-- See https://wiki.hypr.land/Configuring/Start/

-- settings.bind
hl.bind("META + RETURN", (hl.dsp.exec_cmd('ghostty +new-window')))
hl.bind("CTRL + ALT + DELETE", (hl.dsp.exec_cmd('wlogout')))

-- startup
hl.on("hyprland.start", function()
  hl.exec_cmd("/nix/store/x7zw54jlc9yqdq1m4x5lvxscflnczd0s-dbus-1.16.2/bin/dbus-update-activation-environment --systemd --all && systemctl --user stop hyprland-session.target && systemctl --user start hyprland-session.target")
end)

-- shutdown
hl.on("hyprland.shutdown", function()
  os.execute("systemctl --user stop hyprland-session.target && sleep 0.1")
end)

Attachments

No response

I acknowledge that:

• I have searched all (open and closed) discussions and issues and my problem is not there.

• I have read the Code of Conduct and agree to follow it.

• I wrote this request with my own hands, my own keyboard, and in my own words.

[non-bin]

Found it! Previously maximise requests were ignored for unmapped windows

Hyprland/src/desktop/view/Window.cpp

Lines 1457 to 1473 in 5751911

	if (requestsMX.has_value() && !(m_suppressedEvents & SUPPRESS_MAXIMIZE)) {
	if (m_isMapped) {
	auto window = m_self.lock();
	if (window->m_suppressNextMaximize) {
	window->m_suppressNextMaximize = false;
	return;
	}
	const auto CLIENT_STATE = Fullscreen::controller()->getFullscreenModes(window).client;
	// If window's maximised, unmaximise it. If it's not maximised, maximise it.
	if (CLIENT_STATE == Fullscreen::FSMODE_MAXIMIZED)
	Fullscreen::controller()->setFullscreenMode(window, std::nullopt, Fullscreen::FSMODE_NONE);
	else if (CLIENT_STATE == Fullscreen::FSMODE_NONE)
	Fullscreen::controller()->setFullscreenMode(window, std::nullopt, Fullscreen::FSMODE_MAXIMIZED);
	}
	}

But now they are buffered

Hyprland/src/desktop/view/window/Window.cpp

Lines 848 to 863 in 8d50be0

	if (request.maximized.has_value() && !SUPPRESSION.maximize) {
	if (m_isMapped) {
	if (!BACKEND_REQUEST || !m_fullscreenPolicy->consumeExpectedMaximizeEcho(request.maximized.value())) {
	const auto WINDOW = m_self.lock();
	const auto CLIENT_STATE = Fullscreen::controller()->getFullscreenModes(WINDOW).client;
	if (request.maximized.value())
	Fullscreen::controller()->setFullscreenMode(WINDOW, std::nullopt, Fullscreen::FSMODE_MAXIMIZED);
	else if (CLIENT_STATE == Fullscreen::FSMODE_MAXIMIZED)
	Fullscreen::controller()->setFullscreenMode(WINDOW, std::nullopt, Fullscreen::FSMODE_NONE);
	}
	} else if (request.maximized.value())
	m_fullscreenPolicy->setPendingClientRequest(Fullscreen::FSMODE_MAXIMIZED);
	else
	m_fullscreenPolicy->clearPendingClientMode(Fullscreen::FSMODE_MAXIMIZED);
	}
	}

Adding a debug log statement after line 1457 in 5751911 shows the requests have always been coming in which I believe is normal, so I propose adding a config toggle like misc.suppress_initial_maximize_requests to restore the previous behaviour

[Dregu]

If ghostty is actually the only thing you've tested, it has a setting maximize that defaults to false, so you've specifically asked it to do this and now are trying to undo it with a hyprland patch...

[Dregu]

Anyway the idea is not totally doomed, just everything else. We should really avoid options like misc.suppress_this_one_specific_thing_if_its_unmapped_and_its_friday, we have window rules. If there's actual need for doing things to only unmapped windows, add a new window rule prop to match mapped state and now you can apply all window rules to only unmapped windows.

[non-bin]

Sorry if I was unclear, it's everything. Firefox, ghostty, spotify, vscode, libre office, thunar, gnome disks, vlc, etc. The only exceptions I've found are ghostty launched with ghostty +new-window, and vscode windows opened when one is already running.
I think you're right about the weirdly specific option, and I like the window rule idea more. My only concern is that a window rule can't really be defaulted to on, so it would require everyone to add something to their config to restore the original behaviour.

[Dregu]

I get you, just seen a dozen times that "everything I've tried" was actually only kitty and nothing else. Also I can't repro the issue on anything I have, but clearly it has attention so it's probably a real issue?

[non-bin]

Do you have this in your config?

hl.window_rule({
  match = {
    class = ".*"
  },
  suppress_event = "maximize"
});

[zjeffer]

I see the same issue after updating to latest git with firefox, chromium, thunar, gnome-calculator, and probably many more applications. The issue also happens without window rules. My dotfiles: https://github.com/zjeffer/dotfiles/tree/main/.config/hypr

[zjeffer]

It's indeed fixed with this window rule, but it seems weird to me that the window rule is suddenly necessary? Why is suppressing not just the default behaviour?

[non-bin]

I agree! It was the default until #15779 "fixed" it

[non-bin]

Ok. How do we feel about these:

Option 1

More general, probably the better option, but leaves default behaviour in the new state, and must be added manually to config

PR Draft: #15931

hl.window_rule({
  match = {
    mapped = false
  },
  suppress_event = "maximize"
});

Option 2

Not ideal as @Dregu pointed out, but can be set as the default, restoring the previous default behaviour

PR Draft: #15929

hl.config({
  misc = {
    suppress_initial_maximize_requests = true
  }
});

[non-bin]

That rule disables the behaviour, but also disables ALL application initiated maximize requests. I want apps to be able to request maximizing, but not immediately on launch (which was the default until #15779)

[erstarr]

Fair. I'd go with option 1.

[non-bin]

suppress_event is a static effect 🤦
I'm not sure why the static effect distinction is there, but I'm sure I'll piss more people off by modifying that, than I would with suppress_initial_maximize_requests

I think it would be possible to turn suppress_event into a dynamic effect, but I'm not familliar enough with the code to be in charge of that. I think as a band-aid fix the config option would do, but I'll also look into vacerski's comment

[quantumfate]

I prefer option 1 as well. It's more explicit

[non-bin]

Either of you want to have a go converting it to dynamic? I'm not familiar enough with the code base to do it, I'd just be spend hours getting AI to do it before giving up 😋

[vaxerski]

#16013

please check