Mouse events are not passed to some windows when focus_follows_pointer is enabled

[Chrysostomus]

Issue effects at least xfce4-whiskermenu, xfdesktop and desktops drawn by nautilus and spacefm. Desktop items are not clickable and right click menu is unavailable. Whiskermenu can be interacted with through keyboard, but not through mouse.

Setting
bspc config focus_follows_pointer false
Removes all these issues. I haven't observed similar behavior with other windowmanagers with focus following mouse.

[ryneeverett]

Thanks for the workaround, it seems to work.

For me the issue arises simply by switching between two desktops with windows of different mouse styles ("X" and left-pointer). At some point after switching between desktops, the "X" mouse starts persisting in both desktops and has no affect on either until X11 is restarted. As OP notes, the keyboard continues to function fine.

[ryneeverett]

Actually I don't think the the workaround yields any improvement for me.

I can pretty consistently trigger the issue by any interaction with my panel, which I have in the margin created by bspwm padding.

[ryneeverett]

My issues were resolved by recent updates, though I can't figure out which one(s).

[Chrysostomus]

Ryneeveretts issue seems to be separate. There is no change in the original issue. Clicks are not passed to xfdesktop if focus_follows_pointer is set to true.

[baskerville]

Unfortunately, it is probably connected to the way the focus follows pointer is implemented.

See #25 (comment) for the history of this feature.

[eigengrau]

One place where this consistently shows up for me is when I’m trying to run a dock that has a workspace switcher bound to the mouse-wheel (e. g., docky; but the same thing could be observed when I tweaked the example lemonbar to bind the mouse wheel to switch desktops). Now when you keep the mouse wheel scrolling, at some point the desktops stop switching (meaning the dock doesn’t receive the button event anymore). The client will then only receive the events again once the pointer leaves and re-enters the dock window or bar.

[eigengrau]

Another way to reproduce is to open a fresh desktop, start two terminals and run xprop from one. When selecting the client with the xprop pointer, the first time this is done it will not give info on the selected client, but on some bspwm window.

So, after clicking on the termite window, what I get is:

[ ~ ]$ xprop
_NET_WM_PID(CARDINAL) = 30516
_NET_WM_NAME(UTF8_STRING) = "bspwm"
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0xa00000

[baskerville]

As I said before, this is expected and can't be fixed without changing the implementation of focus_follows_pointer.

[rr-]

Same issue here, it's basically the same thing as @eigengrau experiences... I use mouse wheel on a panel to cycle workspaces, and it stops working if there is any window on that workspace (i.e. something receives focus). Trying to regain focus in panel using xdotool or bspc window -f $PANEL_WINDOW_ID doesn't help, all events are ignored until I move mouse out of panel and back into the panel.

Perhaps this may be expected from programming point of view, but not from user experience which is hurt badly as it stands.

[rr-]

Why is the motion recorder needed, isn't XCB_ENTER_NOTIFY sufficient? You've mentioned in #25 issues regarding keyboard focus, but what are these exactly?

In i3, when the focus is changed with the keyboard, the cursor is moved to the center of the window. I'd say this is expected behavior.

[baskerville]

@rr- Agreed: a wm shouldn't get in the way of the user.

[baskerville]

It should be fixed as of 56895ab.

[rr-]

It works! You are the best! 👍 Thank you.

(And I don't notice anything weird about focusing windows with keyboard either.)

[Chrysostomus]

This is beyond awesome! Thank you!

[Chrysostomus]

Yes, it seems to have returned. Apparently the fix broke too many other other important things. A pity.

[rr-]

Perhaps this could serve as an encouragement for writing test suite like the one in i3.

[rr-]

Most of the people seem to be affected by this issue only when using some kind of workspace switcher. For this purpose, rather than coming up with a complex solution that might break irrelevant stuff like it happened the other day, perhaps it would be sufficient to create a separate command that re-focuses the window under the cursor? It would be suitable for scripting purposes (so that people could fire that command after running bspc desktop -f ...), and although a bit dirty, it'd effectively work around the issue.

[baskerville]

@Chrysostomus Have you tried this:

button3
    bspc config focus_follows_pointer off; \
    xdotool click 3; \
    bspc config focus_follows_pointer on

[Chrysostomus]

Initial attempts have been unsuccesful, but in theory that should work. The downside is that it forces the use of focus_follows_pointer afterwards (which is not really a issue for personal use, but might need a workaround since I'm trying to make a bspwm respin for a distro). I'll try some variations to see if I can get it working.

[Chrysostomus]

Okay, this is weird...
button3
bspc config focus_follows_pointer off;
xdotool click 3;
bspc config focus_follows_pointer on
does not work. One reason seems to be that xdotool click 3 seems to also trigger sxhkd command, which causes some sort of loop.
@Button2
bspc config focus_follows_pointer off;
xdotool click 3;
bspc config focus_follows_pointer on
works, but if I add followin after it, it ceases to work:
@button3
bspc config focus_follows_pointer off;
xdotool click 2;
bspc config focus_follows_pointer on

[Chrysostomus]

I just figured why it does not work. If I have hotkey1:
@Button2
bspc config focus_follows_pointer off;
xdotool click 3;
bspc config focus_follows_pointer on
the second mouse button triggers the third mouse button. Therefore if I also have hotkey2:
@button3
bspc config focus_follows_pointer off;
xdotool click 2;
bspc config focus_follows_pointer on
then the third mouse button also triggers the second. Therefore having these two together results in infinite loop of simulating second and third mouse click if I press either of them. Thats why things don't work as expected.

[Chrysostomus]

The issue with workaround seems to be same as this one: baskerville/sxhkd#20
I'll try to the suggested workaround (passing the xdotool click event to a specific window) once I have the opportunity. This is starting to feel remarkably hacky though.

[Chrysostomus]

I tried to pass clicks to the window under mouse with following script:
#! /bin/bash
eval $(xdotool getmouselocation --shell)
xdotool click --window $WINDOW button3

This fails, because when focus_follows_pointer is off xdotool getmouselocation outputs last focused window instead off the one under cursor, and when it is on the click is not passed to the root window.

[Chrysostomus]

I tried with
~button3
clickpasser.sh
#!/bin/bash
##Make sure only one instance of clickpasser is run
if ! mkdir /tmp/clickpasser.lock; then
printf "Failed to aquire lock.\n" >&2
else
exit 1
fi

bspc config focus_follows_pointer off;
xdotool click 3;
bspc config focus_follows_pointer on
&&sleep 1s &&rm -rf /tmp/clickpasser.lock

This prevents the loop, because script can only be run once a second and therefore fails on second run. Click is still not passed however, because sxhkd still graps the xdotool event. So instead of endless loop result is just failed script. The ~ in sxhkdrc makes the mouse button work as normal on windows it usually works, but the root window remains unipressed.

Possible solutions that come to mind:

1. a setting to time/delay the click sxhkd passes with ̃ option by half a second (suboptimal)
2. a setting for sxhkd to ignore (specific) synthetic events (impossible?)
3. a setting for sxhkd to not grab the same mouse event if it repeats too soon before the first (complicated, not fitting for a tool with simple in its name?)

Anyway, I'm out of ideas how to work around this with scripting.

[rr-]

@Chrysostomus to format the code, you can prefix it with four spaces like this:

if (1) {
    exit();
}

using this would increase readability of the scripts you posted.

[baskerville]

@Chrysostomus I could toggle the grabbing state of all the bindings on SIGUSR2...

[Chrysostomus]

Sounds interesting

[baskerville]

Please see if baskerville/sxhkd@ac09ffd helps (you can toggle the grabbing state with pkill -USR2 -x sxhkd).

[Chrysostomus]

Toggling grabbing state with this command seems to work without problems. However, combination

@button3
    pkill -USR2 -x sxhkd; \
    clickpasser.sh; \
    pkill -USR2 -x sxhkd

still fails for some reason. It seems that click generated by clickpasser is still grabbed by sxhkd. I also tried with pkills inside the script, but it made no difference. I suspect it must be something with my syntax.

[Chrysostomus]

@button3
    pkill -USR2 -x sxhkd; \
    sleep 1s &&clickpasser.sh; \
    pkill -USR2 -x sxhkd

works, but with 1s delay and only every other/third attempt. Maybe it has comething to do with duration of the pkill -USR2 -x sxhkd? If sending signal is faster than sxhkd reacting to it.

[Chrysostomus]

With this script it works smoothly

#!/bin/bash
pkill -USR2 -x sxhkd; \
bspc config focus_follows_pointer off; \
xdotool click 3; \
bspc config focus_follows_pointer on; \
pkill -USR2 -x sxhkd

called with this in sxhkd

@button3
     clickpasser.sh

Thank you very much for helping me with this!