Open LanderMoerkerke opened 8 months ago
Can confirm this also happens to me. I'm on v0.34.0
.
Edit: interestingly, using no_cursor_warps
does exactly what I want. I just assumed that this is what mouse_refocus = false
does.
I may be very wrong here, but based on (my reading of) the wiki, it seems that mouse_refocus = false
is supposed to only switch focus when the mouse crosses a window border.
For example: with cursor warps disabled, I use my keyboard to focus window B, while leaving my mouse over window A. I would expect to be able to perform "indirect" mouse actions, like scrolling and hovering, on window A, while window B retains keyboard focus. However, once my mouse crosses over a border onto another window, that window would get keyboard focus as well.
If this is the intent, it doesn't seem to work for me, either. I can switch focus to window B using my keyboard without warping the mouse (thanks to having set general/no_cursor_warps = true
), but the moment I move my mouse within window A (i.e. without crossing a border), window A gets keyboard focus again.
In case it helps clarify, the behavior I'm expecting is akin to follow_mouse = 2
(in that mouse focus is independent from keyboard focus), except that mousing across a window border does switch keyboard focus to the new window.
EDIT: not properly fixed, see below! Adding hy3 to my setup seems to be what "sort of" resolved this for me as described here.
Not sure precisely what's changed, but this seems to have been fixed now (in v0.40.0 or earlier). The setup I describe above, with follow_mouse = 1
, mouse_refocus = false
, and no_cursor_warps = true
, functions as I'd expect. Specifically:
This lines up with my expectations from reading of the wiki.
closing then
I'm a bit confused on if this is working correctly. I'm on the current commit, version 0.40.0.r117.e419ef18-1
.
The current documentation for this commit states mouse_refocus
as follows:
If disabled, mouse focus won’t switch to the hovered window unless the mouse crosses a window boundary when follow_mouse=1.
And with follow_mouse=1
:
1 - Cursor movement will always change focus to the window under the cursor.
With mouse_refocus
set to false
, I interpret that it's expect that, with my keyboard, I can switch keyboard focus from my my current window A to window B. I should be able to send key inputs to keyboard scroll on B, while mouse scrolling (and perhaps move my cursor) freely on A.
In other words, this allows the user to scroll two windows simultaneously.
But currently, mouse scrolling works inconsistently. Starting on window Alacritty A, if I keyboard focus onto Floorp (Firefox) B, mouse scrolling does not work. However, it works going in reverse; that is, Starting from window (Floorp) A, keyboard switching to Alacritty B has mouse scrolling work... but on B, not on A where my mouse is at.
https://github.com/hyprwm/Hyprland/assets/10101319/775e138a-2881-4574-808d-f5152cededb8
I feel like a potential change that could make this easier to manage is to distinctly split focus into "mouse" and "keyboard". Making this concept clear in the wiki, and potentially redesigning how focus works could make this more clear.
Perhaps for individual mouse and keyboard focus, allow the user toggle some rules on how to switch:
As how things work right now, follow_mouse=1
apply (1, 2, 3), =2
apply (3), and =3
applies bindings (4). What I would like to do is (1, 3, maybe 4), which is what mouse_refocus
is supposed to do.
And just to make things clear, mouse focus defines that mouse navigation is passed to that window (maybe clicks too somehow?). Keyboard focus is, of course, that all key inputs are passed to said window.
This discussion on reworking focus warrant its own issue, but currently, mouse_refocus
isn't working, as it seems expected to turn off rule (2) adding rule (1).
I've just performed your browser/terminal scrolling tests on my system (running v0.40.0, commit cba1ade8), and focusing/scrolling work as expected — i.e. scroll events are passed to the window which my cursor is over. Not to say the issue doesn't exist; it's just newer than the current Arch package.
That's a good point regarding configuration logic; I certainly found it hard to follow initially as well. Given that mouse_refocus
only takes effect (per the docs) when follow_mouse=1
, I feel like it might make sense to add a fifth follow_mouse
mode which acts like follow_mouse=1
and mouse_refocus=false
? Just my two cents.
@LRitzdorf could you share with me your hyprland.conf
I'm currently running the most minimal setup and I cannot get any mouse scrolling to work. I also reverted back to v0.40.0 release, non-git. I don't think I mentioned it, but I run Arch.
monitor=,preferred,auto,1
general {
no_cursor_warps = true
}
input {
follow_mouse = 1
mouse_refocus = false
}
$mainMod = SUPER
bind = $mainMod, left, movefocus, l
bind = $mainMod, right, movefocus, r
bind = $mainMod, up, movefocus, u
bind = $mainMod, down, movefocus, d
bind = $mainMod, q, exec, alacritty
bind = $mainMod, r, exec, rofi -show run
bind = $mainMod, k, killactive,
I open two Firefox windows, switch keyboard focus, and I actually can't get any mouse scrolling working at all. Tried with two pcmanfs-qt windows as well, and I could not get any scrolling to work.
Another thing, the moment you move your mouse, even without crossing any window boundaries, Does it bring focus back to the window the mouse moved on? It does for me, which is inconsistent with mouse_refocus
rules. I honestly don't know which rule takes precedent, focus ONLY if crossing border (mouse_refocus=false
) or always on mouse move (follow_mouse=1
).
...okay, this is weird:
hy3:movefocus
dispatcher. Once I reached the point of replacing these with the standard Hyprland movefocus
, the bug reappearedhy3:movefocus
with the standard movefocus
was sufficient to revive the bugIt looks like my initial "fixed" report was actually the result of my having added hy3 between my two tests. I'd assumed this wouldn't affect the cursor/window-focus interaction, but apparently I was wrong.
I have no idea why this would be — @vaxerski (apologies for the ping), any ideas? I'd be happy to test more stuff, as needed. (Also we should probably reopen this issue?)
Edit, further testing: this seems to be the result of the movefocus
dispatcher actually being called (not just adding it to the config file). For example, with the following config snippet:
bind = $mainMod, left, movefocus, l
bind = $mainMod, right, hy3:movefocus, r
Moving focus left/right affects whether the issue occurs, so it seems something about movefocus
resets some kind of internal flag that overrides mouse_refocus
?
The results are as follows: | mouse_refocus |
Dispatcher | Subsequent behavior |
---|---|---|---|
false |
movefocus |
Unexpected (mouse motion focuses window) | |
false |
hy3:movefocus |
Expected (mouse motion doesn't focus window) | |
true |
movefocus |
Expected (mouse motion focuses window) | |
true |
hy3:movefocus |
Expected (mouse motion focuses window) |
no clue, it wasnt me who wrote the feaature and I dont use it so it's possible it was broken some day
As someone not familiar with C++, it looks like CInputManager::mouseMoveUnified()
does some conditional focusing whenever mouse movement occurs. From what I can tell, this focusing doesn't consult the mouse_refocus
option — it seems to be purely based on various internal checks.
Can confirm that this variable is still broken. Current documentation describes this working the same as Sway's default behavior, but it does not actually do anything when enabled or disabled.
https://github.com/user-attachments/assets/78490aaa-177a-4388-90d3-88fdf3bb27d0
❯ hyprctl version
Hyprland, built from branch at commit 9a09eac79b85c846e3a865a9078a3f8ff65a9259 (props: bump version to 0.42.0).
Date: Wed Aug 7 19:17:10 2024
Tag: v0.42.0, commits: 5069
Hyprland Version
v0.33.1
Bug or Regression?
Bug
Description
Following the guide on how to setup Hyprland, the setting input:mouse_refocus = false does not seem give the desirable effect.
How to reproduce
Use config below to reproduce. Switch focus with the keyboard and see that the mouse refocuses even though the setting is turned to false.
Crash reports, logs, images, videos
https://github.com/hyprwm/Hyprland/assets/20244592/f154afab-023f-48c0-ba90-ef8c852434d5
hyprland-logs.txt