Focus problems in multi monitor setup with Google Chrome / Chromium about awesome HOT 24 CLOSED

Yes, reported multiple time over the years on IRC.

from awesome.

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

from awesome.

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

from awesome.

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

from awesome.

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.

from awesome.

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?

from awesome.

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.

from awesome.

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

from awesome.

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

from awesome.

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.

from awesome.

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

from awesome.

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.

from awesome.

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

from awesome.

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.

from awesome.

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.

from awesome.

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

from awesome.

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.

from awesome.

@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?

from awesome.

@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

from awesome.

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

from awesome.

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.

from awesome.

Closing it for now.

from awesome.

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?

from awesome.

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.

from awesome.