With the mouse focus decoupled from the keyboard, the active workspace still follows the mouse

[hariganti]

Already reported ? *

• I have searched the existing open and closed issues.

Regression?

I don't know, I started using Hyprland only recently

System Info and Hyprland Version

System/Version info

Hyprland 0.47.2 built from branch  at commit 882f7ad7d2bbfc7440d0ccaef93b1cdd78e8e3ff  (version: bump to 0.47.2).
Date: Sun Feb 2 00:47:17 2025
Tag: v0.47.2, commits: 5767
built against:
 aquamarine 0.7.2
 hyprlang 0.6.0
 hyprutils 0.5.0
 hyprcursor 0.1.11
 hyprgraphics 0.1.1


no flags were set


System Information:
System name: Linux
Node name: cyborg
Release: 6.13.2-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000


GPU information: 
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 33 [Radeon RX 7600/7600 XT/7600M XT/7600S/7700S / PRO W7600] [1002:7480] (rev c1) (prog-if 00 [VGA controller])
c5:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf] (rev c2) (prog-if 00 [VGA controller])


os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo


plugins:

Description

When moving the cursor between monitors, the active workspace also changes. For example, if workspace 1 is on monitor 1 and workspace 2 is on monitor 2, moving the cursor from monitor 1 to monitor 2 causes the active workspace to shift from 1 to 2.

This has the side effects of:

• Causing windows to open on the wrong workspace when launching an application that opens multiple windows
  • If the cursor is on monitor/workspace 1, but the keyboard focus is on monitor/workspace 2, each window after the first gets placed on monitor 1 rather than monitor 2
• Floating windows, like Rofi and similar launchers, always spawn where the cursor focus is rather than the keyboard focus
• Shifting active focus when a floating window from a special workspace is closed
  • When using pyprland to make a floating terminal, closing it on monitor/workspace 2 with the cursor on monitor/workspace 1 causes the focus to shift to monitor/workspace 1 for new floating items from special workspaces (ex. reopening the floating terminal)
• Resuming after using a lockscreen switches the keyboard focus to the active workspace, which is governed by the mouse focus
  • This is most evident when using the spacebar to play/pause a video, where, after unlocking the computer, you sometimes enter a space into a different application

How to reproduce

1. Set follow_mouse = 2 in the config
2. May or may not be needed, but set no_warps = true as well
3. With a multimonitor setup as described above, keep the cursor on monitor 1 with the keyboard focus on monitor 2
4. Attempt to open something that will open multiple windows, like restoring a browser session, using a launcher like Rofi (Wayland fork) or similar
5. Observe that Rofi opens on the correct workspace and the first window of the application does as well, but all subsequent windows do not

Attach not paste

• I understand that all text files must be attached, and not pasted directly. If not respected, this issue will likely get closed as spam

Checklist of files to include below

• Hyprland config - hyprctl systeminfo -c (always include)
• Crash report (always include in case of crash)
• Video (always include in case of a visual bug)
• Logs (might contain useful info such as errors)

Additional info & File uploads

hyprland_config_dump.txt

[nnyyxxxx]

rofi doesnt have wayland support

[hariganti]

rofi doesnt have wayland support

Under the fourth step to reproduce the issue, I mention to use the Wayland fork.

Additionally, this issue presents even without considering Rofi. For example, resuming from hyprlock.

[vaxerski]

I wonder what this does

[hariganti]

I wonder what this does

And this intentionally doesn't follow the (generally named) follow_mouse setting?

[vaxerski]

correct

[hariganti]

@vaxerski, FYI, even with mouse_move_focuses_monitor set to false, resuming from a session lock (ex. hyprlock) still causes the focus to switch to the monitor with the cursor (fourth side effect listed in original issue). Unless there's another variable I'm missing here, like mouse_on_resume_focuses_monitor...

[vaxerski]

no, that's just how it works. We gotta focus on something, and a cursor in this case is a good enough guide

[hariganti]

Why not just refocus the previously focused window? This is what I've come to expect, from other DEs and WMs so I'd expect the behavior wouldn't be unexpected to many people, and Hyprland clearly has a focus history that could be utilized. Would that be technically infeasible (note: I'm not asking for it to be implemented right now, as I get that it's unlikely a priority)?

EDIT: Evidently hyprctl dispatch cyclenext prev does nothing after resuming from a screen lock. Is the focus history cleared when a screen lock is executed? focuscurrentorlast still seems to work, so I'd assume not...