warp-mouse-to-focus doesn't work when focus is set by wlrctl

[Nairou]

I have warp-mouse-to-focus enabled, which works great when using niri's keybindings to switch between windows and monitors.

However, I've also started experimenting with using wlrctl to focus certain windows, since I can script it and launch the given program if the window isn't open.

Which works great, except that I've noticed the mouse never moves to the window that receives focus in this way. This is especially noticeable when the focused window is on a secondary monitor, and the mouse remains on the primary monitor, requiring an extra step to move the mouse to the focused window without triggering scrolling.

I don't know if this is a wlrctl issue, or a "focus wasn't set by niri" issue, but figured it was worth mentioning.

System Information

• niri version: niri 0.1.6 (unknown commit)

• Distro: NixOS

• GPU: AMD RX 6800 XT

• CPU: Intel i7-8700K

[YaLTeR]

It probably uses the foreign toplevel management protocol to focus a window. The problem is that if we were to warp the mouse to focus there, it would also trigger when clicking on a window in taskbars for example. Since niri doesn't know what kind of event resulted in the focus change through this protocol.

[Nairou]

Very good point, I've been trying to think of a way to satisfy both sides.

Would it be reasonable to assume that if a focus event (of any kind) resulted in focus moving to a different monitor/workspace, and warp-mouse-to-focus is enabled, that the user would probably want the mouse to end up on the new monitor/workspace as well?

[YaLTeR]

Different monitor I can see (I think people generally configure bars to show only the current monitor's windows, so it won't warp on the current monitor); different workspace will hit the same problem though.

I wonder how other compositors handle this?

[Nairou]

I wonder how other compositors handle this?

Coming from sway, it had its own command for changing focus (i.e. swaymsg [app_id='firefox'] focus), so there was no need for an external program like wlrctl.

Adding a similar command to niri is certainly another option, if you were willing to allow it to switch workspaces in order to make the newly focused window visible (automatic focus-workspace). This is the behavior I'm using wlrctl for, so a niri command to do the same would remove the ambiguity about when the mouse should warp.

If automatic workspace switching is a barrier, a simpler option would be to add a command that allows us to query which workspace a window is on (i.e. niri msg get-workspace 'firefox'). This could then be wrapped into a script to first focus-workspace before assigning focus to the window, which would take care of the mouse warping.

[YaLTeR]

Adding a similar command to niri is certainly another option, if you were willing to allow it to switch workspaces in order to make the newly focused window visible (automatic focus-workspace).

That is the plan; pending on some more IPC additions.