Hyprland

Hyprland copied to clipboard

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.

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.

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

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...

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.

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

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.

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

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.

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 ??

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.

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

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.

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

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

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

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.

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

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.

jesus christ y'all are impatient.

fixed in 11afb660102198abb1e74fffdffd00f8c1a11cd9

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.

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.

patches welcome

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)

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)

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..

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 :)

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

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

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

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?