New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Focus follow mouse WHILE holding mouse1 #3429

Closed
Bloodyfool opened this Issue Sep 28, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@Bloodyfool

Bloodyfool commented Sep 28, 2018

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

This comment has been minimized.

Show comment
Hide comment
@i3bot

i3bot Sep 28, 2018

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

i3bot commented Sep 28, 2018

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

@i3bot i3bot added the 4.15 label Sep 28, 2018

@psychon

This comment has been minimized.

Show comment
Hide comment
@psychon

psychon Oct 17, 2018

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

psychon commented Oct 17, 2018

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

@orestisf1993

This comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Oct 17, 2018

Member

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.

Member

orestisf1993 commented Oct 17, 2018

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.

@Bloodyfool

This comment has been minimized.

Show comment
Hide comment
@Bloodyfool

Bloodyfool Oct 17, 2018

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

Bloodyfool commented Oct 17, 2018

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

@orestisf1993

This comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Oct 17, 2018

Member

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.

Member

orestisf1993 commented Oct 17, 2018

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.

@Bloodyfool

This comment has been minimized.

Show comment
Hide comment
@Bloodyfool

Bloodyfool Oct 18, 2018

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

Bloodyfool commented Oct 18, 2018

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

@orestisf1993

This comment has been minimized.

Show comment
Hide comment
@orestisf1993

orestisf1993 Oct 18, 2018

Member

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()
Member

orestisf1993 commented Oct 18, 2018

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()
@Bloodyfool

This comment has been minimized.

Show comment
Hide comment
@Bloodyfool

Bloodyfool Oct 18, 2018

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

Bloodyfool commented Oct 18, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment