Focus follow mouse WHILE holding mouse1

[rwblokzijl]

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

As first described in:
https://www.reddit.com/r/i3wm/comments/8ixzv9/focus_follow_mouse_while_holding_mouse1/
I recently switched distro and with it i went from i3 4.11 to i3 4.13. In 4.11 I could drag and drop chrome tabs to different monitors. Now this is not possible anymore as the target chrome window (on the other monitor) doesn't get focused when i cross the screen boundry.

Expected Behavior

I expect that when a tab is dragged from monitor 1 into a chrome window on monitor 2, that the chrome window gets focused and merges the tab.

Reproduction Instructions

In 328035f or later, open a chrome window on monitor 1, and a chrome window on monitor 2, and drag a tab from one window to the other.

Environment

Anything after: 328035f
Output of i3 --moreversion 2>&-:

i3 version: 4.15

Issue is irrelevant of config.

- Linux Distribution & Version: Debian 9
- Are you using a compositor (e.g., xcompmgr or compton): compton

[i3bot]

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

[psychon]

Possibly related (or not, I'm not sure): awesomeWM/awesome#170 (comment)

[orestisfl]

Yes, I suspected that chrome does something like that. The issue would be avoided if we could maintain focus_follows_mouse while the chrome tab is dragged but I don't think we can do this if chrome grabs the pointer.

[rwblokzijl]

This is not just chrome, focus doesn't change while dragging text between terminal and text editor on different monitors either.

[orestisfl]

Because the application that does the drag grabs the pointer (eg in gtk: https://github.com/GNOME/gtk/blob/1729da8a3e611ce83624663b1cf762080a13eab2/gdk/x11/gdkdrag-x11.c#L2117) and we don't receive events. Nothing we can do about it AFAIK.

[rwblokzijl]

But that still does not explain why this problem does not exist in 4.11.

[orestisfl]

My understanding right now, after the comments in awesomeWM/awesome#170, is that chromium gets the _NET_WM_DESKTOP of a window and if it is different than the current desktop it assumes that the window is not visible, essentially ignoring the existence of setups with multiple monitors:
https://cs.chromium.org/chromium/src/ui/base/x/x11_util.cc?l=542-546&rcl=18040c0c714977c8b98f4117d1e8409137450346 which is called in https://cs.chromium.org/chromium/src/chrome/browser/ui/views/tabs/tab_drag_controller.cc?l=2109&rcl=437b8ad49dc7b0b959794c7ef309ae3447e5018e
If chromium can't get the _NET_WM_DESKTOP property (eg in i3 4.11 when it wasn't implemented yet) it assumes that the window is visible. That's why it used to work.

I am closing this since we haven't found anything i3 can improve on for this issue.

A hacky workaround is to constantly (since i3 will reset it under some conditions) delete the _NET_WM_DESKTOP from all chromium windows. Here is a script using https://github.com/acrisci/i3ipc-python/:

#!/usr/bin/env python
import os
import i3ipc


def on_window(_, e):
    if e.container.window_class == "Chromium":
        os.system(
            "xdotool search --class chromium | xargs -L1 xprop -remove _NET_WM_DESKTOP -id"
        )


i3 = i3ipc.Connection()
i3.on("window", on_window)
i3.main()

[rwblokzijl]

Ah, I understand. Thank you for your time and effort.