Hyprland with on-click causes weird behavior

[mrbman]

Clicking on any module with on-click in waybar or onclick in eww will make the action repeat if you click anything again. If I click an 'onclick' to launch application A, and then a different onclick to launch any other application, application A is always launched again.

This bug was initially reported here however after further testing this issue seems to be specific to hyprland.

[justinesmithies]

I too get the same symptoms as you're getting with Eww bar. When I get home tonight I'll post the error I get from Eww as it mentions a compositor issue.

[Rydgel]

Does it only happen when launching certain kind of apps? Doesn't happen here with pamixer -t on-click

[mrbman]

I did some more testing and have found that (as strange as this seems) if I right click on waybar first (which typically does nothing) I can then click on another app and it works but every subsequent click launches the same app until I right click again. I am also able to replicate this same behavior with an EWW bar.

So if I right click then left click and repeat I can open all of the apps via waybar and eww.

When using the same waybar and eww setup in sway I am unable to replicate the issue.

If there are any commands or logs that will show more detail happy to test more...

[riley-martin]

So if I right click then left click and repeat I can open all of the apps via waybar and eww.

Same here. I am using hyprland-git and waybar-hyprland-git.

[Vanadiom]

System: Arch Installed: waybar-hyprland-git hyprland via paru I also have this issue on waybar-hyprland-git. It seems to be inconsistent somehow, because, this problem:

• does not appear when using the Workspace switcher first, and then something else
• does appear when using something else and then the Workspace mixer.

However I am unsure if the Workspace switcher works using an on-click

[justinesmithies]

I am running latest Arch git version of Hyprland and the latest git version of Eww Bar and all my on-click scripts work fine exept for the one that uses foot terminal to run a script that basically opens a terminal window and runs paru -Syu and waits for obvs the user password then updates and closes. After clicking on that I get the error shown below and clicking on any other thing on the bar then opens the same script again. I have to physically quit and go back in. This is the error I see in Eew Bars logs after that.

warn: input.c:2211: stray button release event (compositor bug?)

All my other scripts for network , brightness and so on all run fine with no issues.

Just tried Eew Bar in my Qtile setup and everything runs perfectly as expected so it's not Eew Bar for sure.

[zoro11031]

I've noticed for me the issue only happens with clickable events that utilize swaync. Everything else behaves normally

[dnkl]

warn: input.c:2211: stray button release event (compositor bug?)

This is from foot. I'm guessing the bar only sees a button press event, and that the release event goes to the launched application.

The bar probably gets confused when it sees two press events without a release in between.

[justinesmithies]

warn: input.c:2211: stray button release event (compositor bug?)

This is from foot. I'm guessing the bar only sees a button press event, and that the release event goes to the launched application.

The bar probably gets confused when it sees two press events without a release in between.

So why does it work if I run the same Eww Bar config with foot under Qtile wayland ??

[dnkl]

It's the compositor that sends the button events to the applications.

In other words, Hyprland is, arguably, sending the release event to the wrong application.

[vaxerski]

can anyone check if the issue also occurs with input:follow_mouse=3?

[justinesmithies]

can anyone check if the issue also occurs with input:follow_mouse=3?

Just tried it and it's the same outcome I'm afraid.

[Vanadiom]

It's the compositor that sends the button events to the applications.

In other words, Hyprland is, arguably, sending the release event to the wrong application.

If this is true we should probably see the event show up when starting wev with waybar, right? Then again maybe the release event qould be too soon for wev to see it.

But the explanation seems rather sound

[abimagnus]

I can also confirm this bug. I am using hyprland-git and waybar-hyprland-git !

[krims0n32]

Looks like its foot specific? I can launch alacritty or any other app (e.g. galculator/pavucontrol) without any issue.

[dnkl]

Foot cannot affect how the compositor sends the button events.

It's most likely a race. Foot is very fast to start. I'm guessing that if an application is "slow enough" to start, the release event will go to the bar instead.

[krims0n32]

Yeah that sounds plausible. Also the reason I don't like alacritty :)

[riley-martin]

I also have a problem of tooltips not showing up after I click. It seems like they do not work again until I right-click somewhere in the bar.

This only seems to occur when launching external applications; I have several waybar modules with a format and format-alt, which switches between them when clicked, and they work fine.

[vaxerski]

jesus christ y'all are impatient.

fixed in 11afb660102198abb1e74fffdffd00f8c1a11cd9

[riley-martin]

This fixes the problem for most apps, but it seems that anything that renders onto a layersurface still has this issue, for example the wayland fork of rofi.

[Aleksanaa]

This fixes the problem for most apps, but it seems that anything that renders onto a layersurface still has this issue, for example the wayland fork of rofi.

Same for me. I'm on 0.20.1+date=2023-01-16_6a56d1e and the issue is still there for rofi-wayland and swaync.

[vaxerski]

patches welcome

[Wakatron]

I am also using hyprland-git and waybar-hyprland-git and have this problem as well. When I launch Wofi and Swaync on-click starts working on the whole area of ​​the panel until I right-click on the panel. (hyprland-git-r2530.76fc1286-1 Waybar v0.9.17-85-g39bc54e3)

[iggut]

I am having the same issues with needing a right click to stop left click from repeating the previous successful left click. These are the current installed packages according to paru:

arcolinux_repo/arcolinux-hyprland-git 23.02-01 [3.47MiB 3.70MiB] [Installed]
arcolinux_repo/arcolinux-hyprland-profile-git 23.01-04 [15.93KiB 35.76KiB] [Installed]
arcolinux_repo_3party/hyprland-dev 0.22.0beta-1 [0B 3.62MiB] [Installed]
arcolinux_repo_3party/waybar-hyprland-git 0.9.17.r66.gea38eec2-1 [0B 2.04MiB] [Installed]
aur/waybar-hyprland-git 0.9.17.r66.gea38eec2-1 [+13 ~4.26] [Installed]

I am also getting the same behaviour with sfwbar as a side note. What I noticed: -When a left click causes a menu to appear, the following left clicks will repeat until the menu is closed AND a right click anywhere on the bar. (waybar or sfwbar) -When a left click is on the idle inhibit, the following left clicks do not repeat (waybar or sfwbar) -When a left click is on the workspace switcher, the following left clicks will repeat until a right click on bar. (waybar or sfwbar)

[Bvngee]

I can comfirm the issue with lbonn's fork or rofi. I've been able to fix the problem by right clicking anywhere on my waybar as mentioned above, or by rapidly spamming the on-click button set to launch rofi followed by escape (probably 15cps), which is interesting..

[fedya-eremin]

Hi there! Me and my friend did some workaround and found out one interesting detail. As it was expressed somewhere above, the issue is caused by mouse release event (rather by its absence). If you try to unfocus opened by Waybar window and then click at Waybar's button, everything is okay. So, you need window to lose its focus right before death. So, there are two (probably) simple ideas we came up with:

• you can make window lose its focus by hyprctl or windowrule with nofocus. The main con is you won't be able to send some input to some apps (e.g. terminal + btop).
• you can emulate event that releases mouse button (like RMB click). One of ways is by ydotool. For example, you may do this: "on-click": "killall gsimplecal || gsimplecal && sudo ydotool click 0xc1" Remember, that you need to add ydotool to sudoers, which is obviously not good, but just solves the problem (kinda reinventing cycle :)

[Aleksanaa]

you can make window lose its focus by hyprctl or windowrule with nofocus. The main con is you won't be able to send some input to some apps (e.g. terminal + btop).

A good find! I hope someone writes a gtk-layer-shell patch to do this. @vaxerski

[and-win]

Hi there! Me and my friend did some workaround and found out one interesting detail. As it was expressed somewhere above, the issue is caused by mouse release event (rather by its absence). If you try to unfocus opened by Waybar window and then click at Waybar's button, everything is okay. So, you need window to lose its focus right before death. So, there are two (probably) simple ideas we came up with:

• you can make window lose its focus by hyprctl or windowrule with nofocus. The main con is you won't be able to send some input to some apps (e.g. terminal + btop).
• you can emulate event that releases mouse button (like RMB click). One of ways is by ydotool. For example, you may do this: "on-click": "killall gsimplecal || gsimplecal && sudo ydotool click 0xc1" Remember, that you need to add ydotool to sudoers, which is obviously not good, but just solves the problem (kinda reinventing cycle :)

Another way to work with ydotool is a add user to input group

ls -l /dev/uinput
crw-rw----+ 1 root input 10, 223 Apr  1 00:27 /dev/uinput

... and enable ydotool daemon with systemd from a user:

systemctl enable ydotool --user

I use such trick to close an active window by click:

"on-click": "/usr/bin/hyprctl dispatch killactive && ydotool click -d 5 0x41 0x81"

It's a poor, but working solution

[Aleksanaa]

Also on nwg-panel. This is still a bug in all gtk-layer-shells, not only waybar.

[and-win]

Also on nwg-panel. This is still a bug in all gtk-layer-shells, not only waybar.

I see no related issues in gtk-layer-shell project. Could you please create it?

[Aleksanaa]

I see no related issues in gtk-layer-shell project. Could you please create it?

But only hyprland has this bug... I'm not sure.

[vaxerski]

should be fixed in f914a5a06d75fcbdf53a03b820fcc8c0ff822b15

I'll wait for someone to report

[Aleksanaa]

should be fixed in f914a5a

I'll wait for someone to report

Will test in 1 sec

[Aleksanaa]

should be fixed in f914a5a

I'll wait for someone to report

Seems not fixed. Tested with waybar launching swaync and rofi-wayland. I'm sure I'm on the latest version.

[OHMCFXG]

should be fixed in f914a5a

I'll wait for someone to report

Looks like it was fixed in b15803510c67b7b89090c99f03781d9052c959f5. I use rofi-wayland and eww.

[Aleksanaa]

Looks like it was fixed in b158035. I use rofi-wayland and eww.

Still can reproduce the bug with hyprland b158035, waybar 0.9.17, rofi 1.7.5+wayland1 and swaync 0.8.0 launched by waybar. But the bug I mentioned earlier may indicate there's also something wrong with latest waybar.

[techsavvyumer]

I am still facing same issue with swaync and wayabar-hyprland-git

[Kvn0l]

Also on nwg-panel. This is still a bug in all gtk-layer-shells, not only waybar.

Noticed today, this really happens with nwg-panel as well, I'm up to date with git version of both; But strangely enough, it's not happening with the button module, only with executors that have click function.

[xbb]

Foot cannot affect how the compositor sends the button events. It's most likely a race. Foot is very fast to start. I'm guessing that if an application is "slow enough" to start, the release event will go to the bar instead.

When I execute swaync-client -t -sw it takes 10ms, slowing it down by adding 100ms seems to workaround the issue for me.

Hyprland v0.25 and Waybar 0.9.17

"on-click": "sleep 0.1 && swaync-client -t -sw",

[techsavvyumer]

"on-click": "sleep 0.1 && swaync-client -t -sw",

Thanks, it works for me too.

[Kvn0l]

Foot cannot affect how the compositor sends the button events. It's most likely a race. Foot is very fast to start. I'm guessing that if an application is "slow enough" to start, the release event will go to the bar instead.

When I execute swaync-client -t -sw it takes 10ms, slowing it down by adding 100ms seems to workaround the issue for me.

Hyprland v0.25 and Waybar 0.9.17

"on-click": "sleep 0.1 && swaync-client -t -sw",

Nice! Using this delay in all my custom modules in waybar seems to have "solved" the issue, but with swaync i had to use 150ms instead, 100ms wasn't enough in my case.

[Aleksanaa]

So the cause is already obvious here... Anyone can submit a patch?

[Aleksanaa]

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1593

[dantefromhell]

the issue is caused by mouse release event (rather by its absence).

I've been seeing mouse click issues with my laptops touchpad and with an external mouse that could be explained by this.

It is especially annoying when playing games and the stuck mouse button triggering an action repeatedly. It happens to both left & right mouse button for me, the way to recover is pressing all mouse buttons eradicly a few times.

[Balssh]

Foot cannot affect how the compositor sends the button events. It's most likely a race. Foot is very fast to start. I'm guessing that if an application is "slow enough" to start, the release event will go to the bar instead.

When I execute swaync-client -t -sw it takes 10ms, slowing it down by adding 100ms seems to workaround the issue for me.

Hyprland v0.25 and Waybar 0.9.17

"on-click": "sleep 0.1 && swaync-client -t -sw",

Confirming this solves my problem with Rofi + Waybar.

[JimitSoni18]

I face the same issue with eww and hyprland latest release (0.33.1) on void linux using sleep 0.1 seems to provide a workaround but i havent understood why

[Aleksanaa]

but i havent understood why

The above reply explained it. It's because hyprland sends all cursor release event to the new top-level layer (such as swaync or rofi) instead of the layer being clicked on (such as waybar or swww) . Adding a delay just makes the launched program start later, so when the release event sends out, the right program receives it, and it will know the next click is a new one.

But this obviously doesn't solve all the problems. If you click on it longer, the bug will appear next time.

[Aleksanaa]

Seems to be fixed in hyprland 0.40.0.