hyprwm / Hyprland

Hyprland is an independent, highly customizable, dynamic tiling Wayland compositor that doesn't sacrifice on its looks.
https://hyprland.org
BSD 3-Clause "New" or "Revised" License
21.99k stars 914 forks source link

Hyprland with on-click causes weird behavior #1348

Closed mrbman closed 4 months ago

mrbman commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

mrbman commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

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

justinesmithies commented 1 year ago

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 commented 1 year ago

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

dnkl commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

justinesmithies commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

krims0n32 commented 1 year ago

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

dnkl commented 1 year ago

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 commented 1 year ago

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

riley-martin commented 1 year ago

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 commented 1 year ago

jesus christ y'all are impatient.

fixed in 11afb660102198abb1e74fffdffd00f8c1a11cd9

riley-martin commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

patches welcome

Wakatron commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

Aleksanaa commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

and-win commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

should be fixed in f914a5a06d75fcbdf53a03b820fcc8c0ff822b15

I'll wait for someone to report

Aleksanaa commented 1 year ago

should be fixed in f914a5a

I'll wait for someone to report

Will test in 1 sec

Aleksanaa commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Kvn0l commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Thanks, it works for me too.

Kvn0l commented 1 year ago

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 commented 1 year ago

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

Aleksanaa commented 1 year ago

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

dantefromhell commented 1 year ago

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 commented 1 year ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 6 months ago

Seems to be fixed in hyprland 0.40.0.