Focus issues with GTK and QT tooltips/menus

ArtemSmaznov commented 10 months ago

Hyprland Version

Hyprland, built from branch main at commit 50a80efad5f9293a2c113545848dd32a61797e23 dirty (flake.lock: update nixpkgs and xdph).

Bug or Regression?

Regression

Description

I have updated hyprland on my system the other day to get the fix for new windows not being focused when switching workspaces and I started to notice that quite often the window I am working on completely stopped responding to mouse clicks until I either switch focus to another window and back or just move my mouse to the waybar and back. #3553 sounds similar but I am not sure if it's the same issue.

After some digging I have figured out the following about the issue:

only seems to be a problem with GTK and QT apps running in wayland (not xwayland)
QT: if you pause the mouse cursor on something to get a tooltip and then move the mouse over that tooltip then the whole window will be locked (the border will indicate that it is still focused). Tested with qutebrowser and digikam
GTK: if you open any context menu then the background window will be locked (you will not be able to close the menu by clicking outside of it). Also moving the mouse around the menu reveals that you can actually select and click stuff withing it while having the mouse outside the menu which seems to be similar to #3553. Tooltips don't seem to be an issue as they are with QT apps. Tested with firefox and seahorse (passwords and keys app).
stuff running in xwayland seem to behave fine. Tested with Brave all of the above is 100% repro rate for me

Some things I have not figured out yet:

Opening new apps that are not the only thing on the workspace seems to have similar issues as I have noticed that the border indicates the right one is focused but when I click with the mouse then the clicks happen on the left window. Not sure on GTK vs QT combos here.
I've also noticed that sometimes I can't select text in alacritty.

I am running with Nvidia GPU so not sure if that will be the cause. I have tried both hyprland-nvidia-git and hyprland-git from AUR and both are the same for me. I have installed hyprland from the core arch repos which is version 0.30 and that one doesn't lock up windows. It does have that weird offset mouse clicks with context menus with GTK apps that I've described above though.

These env variables don't seem to make any difference from what I've seen

GDK_BACKEND,wayland,x11    
QT_QPA_PLATFORM,wayland;xcb
QT_QPA_PLATFORMTHEME,qt5ct

Let me know if you need any more info

How to reproduce

Edit hyprland.conf to only include the following


env = GDK_BACKEND,wayland,x11     # GTK: Use wayland if available, fall back to x11 if not.
env = QT_QPA_PLATFORM,wayland;xcb # QT: Use wayland if available, fall back to x11 if not.
env = QT_QPA_PLATFORMTHEME,qt5ct  # Tells QT based applications to pick your theme from qt5ct, use with Kvantum.

input { follow_mouse = 0 }



QT
1. open qutebrowser running in wayland
2. go to https://wiki.hyprland.org/
3. hover the mouse either on the git or the darkmode icon on the right until a tooltip appears
4. quickly move the mouse over the tooltip without the cursor leaving the window
5. try clicking anything in the window to notice that no clicks are registered (not even the browser tabs)

GTK
1. open firefox running in wayland
6. click on the hamburger menu on the right
7. move the mouse to the left of it and notice that as you move the mouse around items in the menu get highlighted (imagine the context menu was positioned at the top left corner of the firefox window and you would be able to interract with it - in other words it is active in 2 places on the screen and only displayed in it's correct position)
8. try clicking something in firefox outside the context menu and notice that it has no effect

### Crash reports, logs, images, videos

_No response_

vaxerski commented 10 months ago

do you use scaling? if so, this is a dupe of #3553

ArtemSmaznov commented 10 months ago

No, I haven't setup scaling

Monitor DP-1 (ID 0):
    3440x1440@143.92300 at 0x0
    description: LG Electronics LG ULTRAGEAR 210NTQD6G540 (DP-1)
    make: LG Electronics
    model: LG ULTRAGEAR
    serial: 210NTQD6G540
    active workspace: 4 (4)
    special workspace: 0 ()
    reserved: 0 24 0 0
    scale: 1.00
    transform: 0
    focused: yes
    dpmsStatus: 1
    vrr: 0
    activelyTearing: false

Also I am always having special workspaces spawned in case that matters. Issue happens on regular ones with special ones hidden

vaxerski commented 10 months ago

can't repro either qt or gtk

ArtemSmaznov commented 10 months ago

That's unfortunate. Is there anything else I can provide that could help get a hint of where it regressed? I was thinking of making a screen recording recording but didn't think it would be of any use when the issue is all about mouse clicks.

I can try figuring out how to build hyprland manually on the weekend and try to pinpoint the commit where it broke. Hoping there are not too many of them since 0.30

vaxerski commented 10 months ago

git bisect will help

ArtemSmaznov commented 10 months ago

Ow for sure, it building manually what I haven't done much of :)

infra-monkey commented 10 months ago

I'm hitting the same issue with firefox when opening a link in a new tab since latest update. version 0.31.0-1.1 from opensuse tumbleweed repos

hovering waybar gives back focus. Any information I can provide to help?

ArtemSmaznov commented 10 months ago

@vaxerski I have rebuilt hyprland from various commits and can confirm that fb80cbe4 is the one that introduced the issue (I know, the very first one after 0.30).

To be clear I have only tested this with qutebrowser (qt) hover over icons on hyprland wiki as that is the most bothersome for me. I can't confirm if gtk apps have the same history but can retest it later if needed.

Additionally, please note that I haven't used submodules much so I just updated them all to make the build from latest HEAD work (they were failing originally) and didn't touch them throughout git bisect. Mentioning this as I am not sure if this is important and because I was noticing that the unstaged changes section was changing as I was jumping between commits (just the subprojects dir).

I hope this might give enough info to figure out what might have gone wrong here.

PS While confirming a working commit (1b48642f) I have noticed the following: after I hover over a tooltip and them move the mouse cursor over any link on the wiki it doesn't get underlined as it does before the tooltip. Clicking on this commit does work but this seems to me like there might be a deeper issue somewhere further down. Honestly, I can live with this and only the full blocking of the window is a breaking change in my eyes.

sawb commented 10 months ago

I believe this is the same issue as #3415 Additionally, I am using AMD and have this problem too.

ArtemSmaznov commented 10 months ago

Yeah it sounds exactly the same (I have seeing mousing clicking other windows as well when I have multiple tiled). The only thing different is that mine worked on v0.30 and only broke after.

NgoHuy commented 10 months ago

the mouse pointer is null when new window refocused, it should be better logic here.

vaxerski commented 10 months ago

true, try this: patch.txt

NgoHuy commented 10 months ago

the patch worked for me.

ArtemSmaznov commented 10 months ago

Hm... I've rebuilt from AUR and now am on

Hyprland, built from branch main at commit 92cf1c23371e35fa352da13305d8489a9e08d540 dirty (input: fix mouse down handling on unset last surface).
Tag: v0.31.0-42-g92cf1c23

sadly that didn't do anything for me. qutebrowser (qt) and firefox (gtk) still behave as they were before that. Should I try applying the patch and rebuilding manually? Can do this after work.

ArtemSmaznov commented 10 months ago

I have tried rebuilding with the patch and as expected it didn't work in my case either.

vaxerski commented 10 months ago

I still can't repro the qutebrowser one. When I hover over the tooltip, it disappears. Nothing is amiss after that.

vaxerski commented 10 months ago

oh I got it. Had to have follow_mouse at 0. My bad. Omw to fix.

ArtemSmaznov commented 10 months ago

Ow great, I was just recording the video of it and yeah follow_mouse needs to be 0 otherwise focus is forced back as soon as you move the mouse.

ArtemSmaznov commented 10 months ago

@vaxerski this is perfect. Not only do both QT and GTK apps work now but I also get the hover feedback on links and stuff that wasn't working on 0.30 Thank you for the quick fix

vaxerski commented 10 months ago

yours truly

hyprwm / Hyprland