mouse_refocus = false does not work

LanderMoerkerke commented 8 months ago

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.

monitor=,preferred,auto,1

input {
    mouse_refocus = false
}

$mainMod = SUPER

bind = $mainMod, 1, workspace, 1
bind = $mainMod, 2, workspace, 2

bind = $mainMod, left, movefocus, l
bind = $mainMod, right, movefocus, r
bind = $mainMod, up, movefocus, u
bind = $mainMod, down, movefocus, d

bind = $mainMod, J, layoutmsg, cyclenext
bind = $mainMod, K, layoutmsg, cycleprev

bind = $mainMod, Return, exec, alacritty

Crash reports, logs, images, videos

https://github.com/hyprwm/Hyprland/assets/20244592/f154afab-023f-48c0-ba90-ef8c852434d5

hyprland-logs.txt

aos commented 6 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.

LRitzdorf commented 4 months ago

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.

LRitzdorf commented 3 months ago

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:

Window focus can be moved via the keyboard, without affecting the mouse
Performing "indirect" mouse actions (basically anything that's not a click) on an unfocused window keeps that window unfocused
When the mouse crosses a window border, the newly-hovered window gets focus

This lines up with my expectations from reading of the wiki.

vaxerski commented 3 months ago

closing then

uwidev commented 3 months ago

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:

on window border cross
on mouse move
on mouse click
on binding to left, right, up, down

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

LRitzdorf commented 3 months ago

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.

uwidev commented 3 months ago

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

LRitzdorf commented 3 months ago

...okay, this is weird:

Tested with @uwidev's minimal config, which still shows this bug (i.e. moving the cursor within a window forces that window into focus)
Pared down my own config until the bug appeared:
- I normally use hy3, which provides its own hy3:movefocus dispatcher. Once I reached the point of replacing these with the standard Hyprland movefocus, the bug reappeared
Returning to my initial config, I found that replacing even a single instance of hy3:movefocus with the standard movefocus was sufficient to revive the bug

It 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
`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)

vaxerski commented 3 months ago

no clue, it wasnt me who wrote the feaature and I dont use it so it's possible it was broken some day

LRitzdorf commented 3 months ago

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.

df-salaz commented 1 week ago

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

hyprwm / Hyprland