Waybar leaves behind visual glitches when hidden using SIGUSR1

[el-Basketo]

I want to start as usual by mentioning how awesome this project is. Massive kudos to the devs!
But this rock in my shoe has finally annoyed me enough that I'll report it.
Hyprland is supposed to be clean and beautiful, I really hope this gets a fix!

The bug

Workflow

Tiny bit of context to help with understanding.

I want my bar hidden all the time, except when I want to see it.
For this, I have configured hyprland and waybar in such a way that waybar only shows while my mainmod, which happens to be SUPER, is pressed down. The bar also appears on top of all windows, since otherwise you would get a window resize everytime SUPER is pressed.
Not a setup I often see, but to me the advantages are obvious: more screen space!
I know a few others use it as well.
I used to do the same in the i3 days, and I hear sway can do it natively as well.
But hyprland struggles a bit with this use case.

Video of the bug

The problem is that when waybar is supposed to disappear, i.e. whenever SUPER is released, one of 4 things can happen:

1. the bar disappears, this is what we want
2. the bar lingers for a bit, and then disappears, ugly
3. the bar disappears, and leaves behind a sort of "xray zone" for some time, where the parts of any window that were behind the bar become fully transparent, revealing the wallpaper. What!?
4. sometimes it blinks really fast before disappearing. This is much rarer, and I couldn't capture it on video. If specifically requested I will spend time to capture it.

In the video, I synchronised my mouse movements with the pressing of super so that the bug would be more obvious.
Mouse go down = SUPER pressed
Mouse go up = SUPER released

You might need to pause to see it clearly.

video.mp4

How to reproduce

Use a bind to send SIGUSR1 to waybar to hide it while it is in overlay mode.
This is waybar's official way to hide: https://github.com/Alexays/Waybar/wiki/FAQ#how-can-i-temporarily-hide-the-bars

Relevant parts of config

In waybar's config:

{
	...
	"mode": "overlay", // I tried 'hide' as well. 'dock' and 'invisible' are irrelevant here
	"layer": "top", // I tried 'bottom' as well
	"start_hidden": true, // not necessary to reproduce the bug, but makes sense in such a setup
	...
}

In hyprland.conf:

# start waybar, no visible effect since it starts hidden
exec-once = waybar
# to make it appear
bindnt = ,SUPER_L , exec, pkill -SIGUSR1 waybar
# to make it disappear
bindntr = SUPER, SUPER_L, exec, pkill -SIGUSR1 waybar

The weird tricks you see in my hyprland.conf are only here to allow it to trigger once on "mod press" and once again on "mod release". But the bug also happens with a regular bind = $mod, B, exec, pkill -SIGUSR1 waybar, or even when running pkill -SIGUSR1 waybar directly from the command line.

I repeat: the bug is unrelated to the weirdness of my config and happens whenever SIGUSR1 in sent to waybar to hide it if it is in overlay. Which my config happens to do.

Research and tests

This to me is clearly a render issue. Also, it:

• happens whether blur, animations, gaps, shadows are enabled or not
• happens whether decoration:blur:new_optimizations is enabled or not
• is possibly related to Artifacts beneath waybar with fractional scaling #10322
• is unrelated to debug:damage_tracking,it happens with any of 0,1,2

System information / related files

• Fedora Linux 41
• Hyprland 0.49.0 built from branch at commit 9958d29 (version: bump to 0.49.0) (courtesy of Solopasha)
• Waybar v0.11.0

Result of hyprctl systeminfo -c, somewhat redacted. Relevant part is at the very end.
hypr_config.txt

EDIT1: changed a bullet list to a numbered list for clarity

[vaxerski]

can you post WAYLAND_DEBUG=1 waybar ... (your args) ... |& tee ~/log.txt from when you hide it with sigusr1?

[el-Basketo]

Hi, thanks for the attention!

I actually ran WAYLAND_DEBUG=1 waybar &> ~/log_waybar.txt & sleep 5 && pkill waybar and sent it SIGUSR1 a couple times by pressing SUPER during those 5 seconds.

Here is the log :
log_waybar.txt

This log does contain occurrences of behaviors 1 (intended), 2 (bar lingers) and 3 (windows getting cut). Not 4 (flicker).

[el-Basketo]

And just for good measure, here are the results of a similar test, this time with waybar -l trace &> ~/trace_waybar.txt & sleep 5 && pkill waybar. Just in case it ever becomes useful.

Spoiler: I didn't find anything interesting in this one.

trace_waybar.txt

[vaxerski]

hm, odd. I don't have the time rn to debug this but it's generally damage tracking. I don't really see the mechanism of how waybar hides itself in the log tho

[el-Basketo]

Solved!

Dude, just updated Fedora 41 -> 42 and the bug is gone.
No idea what solved it since many packages got upgraded in the process.
If I had to guess, I would say probably the waybar 0.11 -> 0.12 version bump…

Anyways, it is insanely responsive and snappy now, I am happy.
(very minor blur glitch during approx. 1 frame when the bar disappears, but idc about this one, it is barely noticeable)

New system info

• Fedora Linux 42
• Hyprland 0.49.0 built from branch at commit 9958d29 (version: bump to 0.49.0) (still solopasha)
• Waybar v0.12.0

[vaxerski]

happy you got it fixed