~#15343~ *hyprbars* breaks top areas of window

[winkelnp]

Since v56.0, clicks in the top bars of any window have stopped registering for me. I assume this is because that is registered as "window decoration", and since #15343 expects a drag event.

I do not use these drag events, would it be possible to (add an option to) disable that? To me it is entirely superfluous as SUPER+drag works fine, as well as just my normal keybindings, whereas this way it actively stops accepting clicks in the top section of quite a few apps.

I also seem to have ghost decorations now, clicking the top right corner of any app closes it, even if I have csd disabled, and fullscreening right next to it. This actively hurts usability, as this means that this area acts as a close button but has no visual indicator, meaning any buttons that happen to be there (eg hamburger menu in gtk apps) are now inaccessible and just close (shown below in video)

2026-07-23.23-11-14.mp4

[wabarTM]

there is a "no_drag" windowrule pr already, but "fuck_csd/ssd" rule would be good too

[tekstryder]

Hi @winkelnp, no_xdg_drags is available as of commit e820db9.

• desktop/rule: add no_xdg_drags window rule #15573

Please test and confirm this works for your use-case.

[winkelnp]

Just tried it, seems to work a charm, however the issue I was experiencing seems to be mainly due to hyprbars functioning despite being set to enabled=false in config

[Dregu]

Yeah I'm pretty sure all issues about xdg drag are actually about hyprbars until proven otherwise.

[winkelnp]

Sorry for the confusion 😅 I assumed as I had enabled=false in my config, simply loading the plugin would do nothing, only dawned on me when nothing changed with the no_xdg_drags windowrule… I will still be using that windowrule when it is part of a release, but simply disabling hyprbars for now is good enough as a bridge for the main issue I had.