Focus problems in multi monitor setup with Google Chrome / Chromium

[HerrBerg]

Problem:
I use awesomewm v3.5.6 and have the following problem in a multi-monitor setup:
When I use chromium browser I cannot rearrange tabs using the mouse. When I try to drag a tab I instantly get a new window with that tab. After that it is not possible to move this tab back into the main window.
Another issue: in the bookmark manager (of chromium) it is not possible to reagange the bookmarks using drak and drop either.

Why I think this is an awesomewm issue:
Today I found, that these issues only occur on screen two and three.
On screen one everything works fine.
More precisely: it only works on the primary monitor (see below)

What I did to setup monitors:
xrandr --output eDP1 --auto --primary --output DP4 --auto --right-of eDP1 --output HDMI1 --auto --right-of DP4

the screen where I can move tabs moves with the --primary flag

[blueyed]

Thanks for filing this. It is a known issue AFAIK.

[Elv13]

Yes, reported multiple time over the years on IRC.

[vdrandom]

It is the case with most chromium based applications, including github's Atom editor. The only exclusion among chromium based browsers I know is Opera. So if you are desperate to use a chromium-based browser for some reason, you can stick with Opera, at least for now.

[chpill]

I'm experiencing the exact same bug (awesome v3.5.6) . The drag and drop inside a chrome web page works only on the primary monitor.

Does anyone have any idea why chrome behaves this way?

[berlam]

Just for the docs. This bug was reported to the chromium team also:
https://code.google.com/p/chromium/issues/detail?id=132706

Already closed unfortunately.

[schmellow]

I wonder where one should start looking to pinpoint the problem. Since tab dragging works in i3, i was skipping through both awesome and i3 source code, trying to find significant differences in window and mouse handling code to get some clues, but to no avail (even though significant differences are aplenty, haha).

So, tab dragging works in i3 both for primary and secondary displays by default. BUT, while playing with chromium i was able to reproduce exactly same erroneous behaviour in i3.

Steps:

1. Open chromium on primary screen
2. Make it floating
3. Drag it to secondary screen

Dragged window and all its children (created by ctrl+n command) will exhibit the behaviour in question while being on secondary monitor.

Alternative steps:

1. Open chromium on secondary screen (tab dragging works)
2. Make it floating
3. Drag to primary and back -> same story

Oddly enough it's not reproduceable in bspwm, so probably gonna look there as well

[psychon]

@schmellow If you really dare to do so, I'd recommend to look into Chromium's source code. How do they implement this? What's different in the non-working case? But I guess that this isn't exactly trivial to do...

[mavaa]

Just chiming in since I am also having this issue, and I'm willing to help digging into it if there's anything I can do to help. I'm a bit busy the next week and during easter, but I'll probably start trying to build both Awesome and Chromium from sources when I can find some time for it :)

[schmellow]

Uhh...chromium. Using builtin tracing i narrowed it down to TabDragController::GetTargetTabStripForPoint. Somehow chromium can't get existing tab strip for current mouse location and decides it should create a new window. That covers initial detachment and probably indirectly there is the reason window can't be reattached.

As of why it happens, there are multiple potential points of failure: it may fail to get window at coordinates at all, window may not be a chromium one, tabstrip bounds may be out of place etc etc. To know for sure ideally i need to do a step by step debug, and that's where i'm stuck currently.

[blueyed]

I could imagine this being related to some method trying to get the current display/monitor, which could be related to #759.

[schmellow]

You are totally right, psychon's second comment here was like an eureka moment.

It all works properly in i3 and bspwm because they store their workspaces structured, in a tree, so they can enumerate them consistently. And they do - they traverse the tree and set _NET_CURRENT_DESKTOP equal to index of currently focused workspace.

You can emulate this in awesome:

1. do "xprop -root", and count entries in _NET_DESKTOP_NAMES.
2. Move chromium to secondary monitor
3. do "xprop -root -f _NET_CURRENT_DESKTOP 32c -set _NET_CURRENT_DESKTOP n", where n is index of corresponding tag

And it starts working.

Now im not sure how to approach this problem now, since solution may not stand well with current tags implementation, I can try to sketch something though.

[blueyed]

Then I could imagine a fix being to set the focused tag (from what awful.screen.focused() provides), instead of the first selected one (done in

awesome/ewmh.c

Line 262 in 491f17f

uint32_t idx = tags_get_first_selected_index();

)?!

[schmellow]

Little more complicated, considering that:

1. As of now, current desktop is being updated on tag switch
2. Screen focus follows mouse:

   awesome/lib/awful/screen.lua

   Line 152 in 491f17f

   function screen.focused()

3. Current desktop value must be synchonized with index of entry in _NET_DESKTOP_NAMES
4. Cases when current desktop must be updated:
   4.1) User switches tag and this tag belongs to screen that is currently focused
   4.2) On screen focus change (not implemented currently?)
5. Cases when it should not be updated:
   5.1) User switches tag and the screen this tag belongs to is not focused
6. Multiple tags can be active on screen

So it becomes like this

1. Get focused screen
2. Get tags matched to this screen
3. Get active tag
4. Cycle tags from globalconf.tags (like in ewmh_update_net_desktop_names) with counter until matching tag is encountered
5. Assign counter value to _NET_CURRENT_DESKTOP

Maybe there is more concise solution, still how to adress (6)? Take first active tag? That will have to be tested

[blueyed]

Thanks for analysing this!

6. Multiple tags can be active on screen

Taking the first active tag (more or less the current behaviour) seems to be sensible in that case.

[Elv13]

Taking the first active tag (more or less the current behaviour) seems to be sensible in that case.

Actually, it is what Awesome itself does. There isn't really multiple tags. What happen is that a new client list is created with the clients from all selected tags and it forced into the first tag. The layout and properties are those of the first tag.

[blueyed]

@Elv13
I think you did not get the problem/issue: it seems to be that _NET_CURRENT_DESKTOP is the first selected tag always (likely from screen 1, even if you're on screen 2).

[Elv13]

No, I got that, I can also reproduce the bug and all. I was just pointing out that using the first tag in a multi-tag selection is the right thing to do and and already what is being done elsewhere in Awesome when faced with other issues caused the 0-n cardinality.

[psychon]

@schmellow So you are saying that chromium looks at _NET_CURRENT_DESKTOP on the root window and _NET_WM_DESKTOP of its own windows and considers its window to be invisible when the two don't match. Thus it wrongly concludes that the tab cannot be attached to its window, even though in reality it could. Did I get this right?

[schmellow]

@psychon Looking at chromium sources for a second time, yeah, i think this is it. It tries to find window at pointer location, ignoring all invisible ones. And visibility depends on window's assigned desktop and current active desktop: https://code.google.com/p/chromium/codesearch#chromium/src/ui/base/x/x11_util.cc&q=GetWindowDesktop&sq=package:chromium&type=cs&l=570

[blueyed]

Could anybody of the affected people try out #910, please?

[psychon]

Now that #910 is merged, I think that this is fixed. Feel free to report here if this issue is indeed fixed for you with latest git/master and please speak up if the problem remains.

[blueyed]

Closing it for now.

[zetaPRIME]

I'm having this exact issue on Awesome 4.2, more specifically with not being able to drag and drop between windows on different monitors. Same (well, mostly same) root cause (_NET_WM_DESKTOP being a different value between the source and target); any fix or workaround available?

[dm17]

I was having it for a while on this awesomewm version, but it stopped for some reason (the entire browser window was greyed out / out of focus, and I had to start it on the primary display and then move it to the external to be in focus).
I do however have trouble with chrome limited to 60hz. I think it is related to the primary display in Xorg (laptop display) being 60hz, while the external display is 144hz. Do others have this issue as well? As I understand it, programs should know their windows are on a 144hz display and not limit themselves to 60hz.