Cursor wraps to the center of the window on certain contextual menus and tooltips

[Zhaith-Izaliel]

When accessing a contextual menu (in Sonobus for example) or when a small tooltip spawns in QT applications (like Krita), the cursor wraps to the center of the window, often rendering the tooltip and/or contextual menu impossible to use.

This only occurs with hyprscroller and not base Hyprland, which indicates me it's a problem with the plugin. You can mitigate the issue by setting cursor::no_wrap = true but I don't think it's a sustainable solution.

Hyprland version: v0.46.2
Hyprscroller version: e250f38

[dawsers]

So that I am able to reproduce your issues...are you running those applications in Wayland or X mode? I run Krita and many other Qt apps in Wayland mode and I don't have any issues. These are most of the environment variables in my hyprland.conf

env = GTK_THEME,Adwaita-dark
env = QT_QPA_PLATFORM,wayland;xcb
env = GDK_BACKEND,wayland,x11
env = SDL_VIDEODRIVER,wayland
env = CLUTTER_BACKEND,wayland

env = XDG_CURRENT_DESKTOP,Hyprland
env = XDG_SESSION_TYPE,wayland
env = XDG_SESSION_DESKTOP,Hyprland

# Electron
env = ELECTRON_OZONE_PLATFORM_HINT,wayland

env = QT_AUTO_SCREEN_SCALE_FACTOR,1
env = QT_ENABLE_HIGHDPI_SCALING,1
env = QT_WAYLAND_DISABLE_WINDOWDECORATION,1 # Disables window decorations on Qt applications
env = QT_QPA_PLATFORMTHEME,qt6ct
# This is to (temporarily) fix font rendering on QWebEngineView 6
# (qutebrowser, goldendict etc.)
# https://bugreports.qt.io/browse/QTBUG-113574
env = QT_SCALE_FACTOR_ROUNDING_POLICY,RoundPreferFloor

# NVIDIA environment variables
# https://wiki.hyprland.org/Nvidia/
env = LIBVA_DRIVER_NAME,nvidia
env = XDG_SESSION_TYPE,wayland
env = GBM_BACKEND,nvidia-drm
env = __GLX_VENDOR_LIBRARY_NAME,nvidia

Like you mention, there is also the option cursor:no_warps = true, but first let's figure out what the problem is.

[Zhaith-Izaliel]

Hi, thanks for the fast reply.
So I tested with the environment variables you provided (albeit without the NVidia ones since I'm on AMD) and I still can reproduce the issue, with these variables or not.

I can link you my config, though most of the variables are managed with Nix, so they won't appear in hyprland.conf

[cpiber]

Fairly certain this is related to #74 and #77. Hyprscroller is more aggressive in warping the cursor than base hyprland, I noticed the same in some windows with weird tooltips, e.g. matplotlib's standalone plot window

[dawsers]

So I understand you are running the Wayland backend for Qt instead of XWayland? Just to double check, with one of the problematic applications open, paste the result of hyprctl clients, so we are sure there is no XWayland involved.

It would be good if you could provide a simple procedure where I can verify the issue. For example, I also have Krita installed on my system, so that would be a valid app for me to test. Tell me something you do there that shows the issue. Or if you have a simple program that shows it very clearly and I can install it too, that would be also useful.

[dawsers]

Fairly certain this is related to #74 and #77. Hyprscroller is more aggressive in warping the cursor than base hyprland, I noticed the same in some windows with weird tooltips, e.g. matplotlib's standalone plot window

Yes, I agree, that is why I would like to have a simple case I can reproduce. Matplotlib would also work if you can provide an example.

[cpiber]

import matplotlib.pyplot as plt
plt.plot()
plt.show()

In the new window try to hover any of the buttons in the toolbar below.

And yes, that does seem to be running xwayland:

Window 5ec1006ba0e0 -> Figure 1:
	mapped: 1
	hidden: 0
	at: 1679,42
	size: 1416,1116
	workspace: 3 (3)
	floating: 0
	pseudo: 0
	monitor: 0
	class: Matplotlib
	title: Figure 1
	initialClass: Matplotlib
	initialTitle: Figure 1
	pid: 194392
	xwayland: 1
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags: 
	swallowing: 0
	focusHistoryID: 1
	inhibitingIdle: 0

[dawsers]

OK, so it's definitely related to XWayland, because using my backend for matplotlib I don't have that problem, and I see I am running on pure Wayland.

I use qtagg, which I think it is the default, but I am using Qt under pure Wayland, by setting the environment variables in the previous comment.

Window 561013231540 -> Figure 1:
	mapped: 1
	hidden: 0
	at: 11,49
	size: 1518,1667
	workspace: 5 (5)
	floating: 0
	pseudo: 0
	monitor: 0
	class: python3
	title: Figure 1
	initialClass: python3
	initialTitle: Figure 1
	pid: 175644
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags: 
	swallowing: 0
	focusHistoryID: 1
	inhibitingIdle: 0

[dawsers]

OK, changing my backend to xcb shows the problem. I will investigate. In the meantime, I recomment using the Wayland backend for Qt. It works fine and we are using a Wayland compositor anyway,

env = QT_QPA_PLATFORM,wayland;xcb

[cpiber]

For matplotlib specifically, I had to install PyQt6 for it so select a compatible backend, but with that it works, as you say. Unfortunately, not all applications are as easily fixed

[dawsers]

Of course, I am not trying to bury the bug. I just wanted to know if it is related to XWayland. There are lots of special cases in Hyprland for that backend. I try to stay away from running any apps that only work under X, and that is why I hadn't seen the problem. I will investigate. I probably forgot something they added specially for XWayland.

[Zhaith-Izaliel]

So I retested in multiple setups and I'm absolutely unable to run QT apps with wayland on my machine, and I don't know why. It's frustrating.

But glad to know it's only a problem with XWayland, I'll find a way to stop this nonesense with QT when I have more time on my hands

[dawsers]

So I know what is happening. X creates a window for tooltips, so when the tooltip disappears, the window is closed. At window closing, there is a change of focus to the new active window, and that includes a cursor warp.

I will try to better understand what the implications of disabling cursor warping when closing windows are, but in reality, there is an option for that already: cursor:no_warps = true. You can use that in the meantime.

[dawsers]

I have done some testing. If I remove cursor warping when closing a window, the cursor will stay where it is. So when I close a window, the new focused window will be the one after it, as expected, but the cursor may be over another window, so as soon as I move the mouse, focus changes to the window where the cursor is pointing. That may create unwanted scrolling and unpredictable behavior as soon as one touches the mouse. I think we discussed this when dealing with the previous bugs. I don't like that.

Hyprland doesn't need to warp the cursor because it actually focuses on the window that stays open at the position of the cursor.

So I could offer an option to do what Hyprland does:

Don't warp the cursor in specific cases like closing windows. That would fix this issue the same way that using Hyprland's own cursor:no_warps = true fixes it, but it would still warp the cursor in other cases when the user actually wants that to happen, like when actively changing focus. This would change which window is focused when a window is closed. In some cases, it won't be the next of the row. That option cannot be the default, as it breaks current behavior.

Also, these "tricks" of opening windows like they have to do with X applications will end up disappearing.

Let me know what you think or if you have a better idea.

[cpiber]

Don't warp the cursor in specific cases like closing windows.

That sounds nice to me. Can you detect if the window is floating? If so, that may be interesting. When closing a tiling window, most users probably still want the cursor to warp, but a floating window not so much. But in general this is a bit of a weird case...

[dawsers]

Yes, but those tooltip windows are not floating, they are tiled. I get a onWindowRemovedTiling() call when they close. Otherwise, we wouldn't have this problem, because when removing floating windows I don't warp the cursor.

It will be relatively transparent, because there will be focus on the window under the cursor instead of the one after the closed one, so the weird animation will happen at close if it has to, instead of when moving the mouse.

[dawsers]

OK, so there was a way to detect those windows without breaking any behavior, so I ended up fixing it and not adding any new options.

Fixed in 7385ab8

Let me know if you still encounter any problems.

[cpiber]

Sorry for the late reply, for me that works quite nicely. Matplotlib with the TkAgg backend still has some problems (see video attached), but that's probably an edge-case in the library, not your problem, since it only happens on the border of the button. Notice the flashing border as hyprland switches focus (but the mouse doesn't warp).

Video_2025-01-22_10-12-30.mp4

[dawsers]

I see it, but it also happens using the Dwindle layout in my testing. So it is just XWayland creates a window for the tooltip and changes focus back and forth. I think it is unrelated to the plugin.

[cpiber]

env = SDL_VIDEODRIVER,wayland

Btw, I'd be careful with that. Had to debug for quite some time yesterday to figure out why some of my games weren't starting anymore. Turns out Unity bundles such an old version of SDL that the wayland backend fails to initialize, so the games crash later on. Unfortunately, SDL doesn't allow a backup driver like QT and GTK

[dawsers]

Yes, thanks. I tried to go hardcore Wayland and then backtrack if things don't work. Fortunately, I don't game much, because Wayland and gaming still have some rough edges. Even Wine 10, which supports a Wayland backend doesn't turn it on by default. I will make a note about this one, thank you.