Spawning a new top layer over a FS window makes it show

[FakeMichau]

Hyprland version

v0.56.2

Is this a regression?

I do not know

What's the bug?

Top layers shouldn't be visible over a fullscreen window.
Spawning/Creating a top layer while a fullscreen is active makes that layer visible. Switching workspaces back and forth results in the intended behavior - top layer becomes hidden.

In my specific example, i've used noctalia's notifications. I've checked that it is creating the notification as a top layer by using hyprctl layers.

It might have something to do with the creation of a new layer because after switching workspaces back and forth, while the notification is still active, spawning more notifications don't make them show up. I have to wait for the notifications to timeout and then the issue can be recreated again.

The issue seems to be kinda similar to #14737 but not quite because I don't see an issue with the bar. The bar's top layer is created before the FS window so my specific issue doesn't happen. But if I launch the bar while the FS window is active then my issue shows up.
The issue in #14828 is potentially the result of my issue. I don't want top layers to show in games because I want DS to be active, OSD or notifications break that.
While the issue on #14721 seems related, I do not use scrolling layout.

Reproduction steps

1. Launch a fullscreen window
2. Somehow spawn a new top layer (I've used notify-send '' bound to a key)
3. Top layer is visible while it shouldn't

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.

[erstarr]

They are visible above it because you are spawning a new layer.

They go away when you cycle FS because all layers that were created before the window is FSed, regardless of level, are hidden.

People would like notifications to show when they get them even when they are fullscreen.

[FakeMichau]

Noctalia has an explicit toggle for this for all the various windows; that accurately describes the fact that only overlay layer will be shown in fullscreen applications.

The devs there seem to make a conscious choice to use the top layer by default for everything but the launcher.

Currently there is no choice. If this bug will become seen as a feature then I'm left with patching hyprland which is silly.

[erstarr]

The devs there seem to make a conscious choice to use the top layer by default for everything but the launcher.

Odd that.

Yeah that makes little sense to me. I concede the point; only overlay should be above fullscreen.

A quick peek into the code confirms that this should have been the case originally in any case:

Hyprland/src/desktop/view/LayerSurface.cpp

Line 344 in af0d014

// if in fullscreen, only overlay can be above.

Noctalia should change which layer they populate with their notifications (if the problem is indeed that top layer somehow makes it through ontop of fullscreen)

I'll look into this.

[Dregu]

Boils down to the protocol specification: tl;dr fullscreen and top layer are equal, and since they can't be drawn at the same time, drawing them in the order they were created makes the most sense. That's assuming the protocol makes sense, which it doesn't, since there's actually no layer that's clearly between normal windows and the fullscreen window. Top is simply the same as fullscreen.

But since it's one of those "do whatever the fuck you want, here's the name" kind of wayland protocols, of course all compositors do it differently. I agree that 100% of top layer should be below the fullscreen window, someone else might like the creation order logic. So it probably needs options.

Fullscreen shell surfaces are typically rendered at the top layer. ... ordering within a single layer is undefined.

It's impossible to say what's the right way or the wrong way.

[FakeMichau]

If there is a concern of some users relying on this behaviour then just having a config would be awesome. I did see that spec but brushed it off as me just not finding the correct website as I didn't believe it could be so ambiguous.

I can only say that from my perspective as a user having a layer that has the ability to draw over normal windows but not FS windows is useful.

[tcz0g]

I'm no expert so i don't know if the following is helpful.
I noticed odd behavior with noctalia as well when the dock is using the top layer where it would randomly spawn on top of a fs window.
It didn't use to happen in 0.55.4 so its like a regression these should be relevant
50e7fdd
254d6ba

it has not been fixed in af0d014.

To me it looks like the flag LAYER_FLAG_ABOVE_FULLSCREEN is unconditionally set in:

Hyprland/src/desktop/view/LayerSurface.cpp

Lines 173 to 178 in af0d014

	void CLayerSurface::onMap() {
	Log::logger->log(Log::DEBUG, "LayerSurface {:x} mapped", rc<uintptr_t>(m_layerSurface.get()));
	m_mapped = true;
	m_interactivity = m_layerSurface->m_current.interactivity;
	m_flags |= LAYER_FLAG_ABOVE_FULLSCREEN;

so there is no check anywhere in the function at map time, it should be conditional like in the later functions

onCommit() does it like so:

Hyprland/src/desktop/view/LayerSurface.cpp

Lines 338 to 345 in af0d014

	m_layer = NEW_LAYER;
	if (NEW_LAYER >= ZWLR_LAYER_SHELL_V1_LAYER_OVERLAY)
	m_flags |= LAYER_FLAG_ABOVE_FULLSCREEN;
	else
	m_flags &= ~LAYER_FLAG_ABOVE_FULLSCREEN;
	// if in fullscreen, only overlay can be above.
	*m_alpha.get(LS_ALPHA_FADE) = Fullscreen::controller()->hasFullscreen(PMONITOR) ? (m_layer >= ZWLR_LAYER_SHELL_V1_LAYER_OVERLAY ? 1.F : 0.F) : 1.F;

looking back at 0.55.4 it was also unconditional aswell but a top layer could still be kept invisible because the visibility was tied to the alpha and was carried by its state so having

Hyprland/src/desktop/view/LayerSurface.cpp

Line 164 in a0136d8

m_aboveFullscreen = true;

unconditional didn't really matter

remapping

Hyprland/src/desktop/view/LayerSurface.cpp

Lines 170 to 172 in a0136d8

	// this layer might be re-mapped.
	m_fadingOut = false;
	g_pCompositor->removeFromFadingOutSafe(m_self.lock());

was dropped entirely or is it handled by the new FadingOutState?

last thing is that onUnmap

Hyprland/src/desktop/view/LayerSurface.cpp

Lines 258 to 266 in af0d014

	const auto SNAPSHOT = !m_ruleApplicator->noanim().valueOrDefault() ? g_pHyprRenderer->makeSnapshotFB(m_self.lock()) : nullptr;
	const auto SOURCEALPHA = m_alpha.getTotal();
	// FIXME: this shouldn't be needed but it is because style is decided by the fuckin anim from this
	m_realPosition->setConfig(Config::animationTree()->getAnimationPropertyConfig("layersOut"));
	m_realSize->setConfig(Config::animationTree()->getAnimationPropertyConfig("layersOut"));
	m_alpha.get(LS_ALPHA_FADE)->setConfig(Config::animationTree()->getAnimationPropertyConfig("fadeLayersOut"));
	Desktop::fadingOutState()->add(CLayerFadeout::create(m_self.lock(), SNAPSHOT, SOURCEALPHA));

doesn't this workaround makes it so the onMap function doesnt know whats happening because its a seperate object in onUnmap so it fades back to 1?

[erstarr]

#15937

[erstarr]

Please test with your shells. Is the bar still focusable under FS, etc?