awesome

Welcome to awesome bug tracking system.
Tasklist

FS#1011 - GNOME panel can have focus

Attached to Project: awesome
Opened by Julien Danjou (jd) - Monday, 25 June 2012, 08:49 GMT
Last edited by Uli Schlachter (psychon) - Friday, 06 July 2012, 15:34 GMT
Task Type Bug Report
Category Core
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.4.12
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

GNOME panel (gnome-panel) can now receive focus from awesome 3.4.12. This used to not happen in 3.4.11. Something changed and caused this regression.

FYI This has been reported by Stefano Zacchiroli <zack@upsilon.cc> so he can be asked for detail, but it seems easy to reproduce.
This task depends upon

Closed by  Uli Schlachter (psychon)
Friday, 06 July 2012, 15:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  For 3.4, I took the easy way (requiring changes in every user's config is just no good option):

commit c084eb5b085287e4fb2661e834197cf8cf233215
Author: Uli Schlachter <psychon@znc.in>
Date: Fri Jul 6 17:32:53 2012 +0200

Revert "Focus history: Don't ignore unfocusable clients"

This reverts commit c0dffca646c1a02276da510bf3587fb7fad8e0e9 which caused
 FS#1011  . This is just too much breakage which can't easily be fixed in 3.4.

For master I committed the proposed patch:

commit 48c6c11d1721f40ec5136cfbd4a8125e4208277f
Author: Uli Schlachter <psychon@znc.in>
Date: Fri Jul 6 17:30:35 2012 +0200

awful.rules: Implement callbacks for individual properties

When a property is now set to a function, the function's return value will be
used for the value of the property. The function gets the new client as its only
argument.

There is no property which accepts a function as its value and thus this change
can't break anything (yeah, famous last words...).

This should fix half of  FS#1011  . Panels now don't get focused by awful.rules.

Signed-off-by: Uli Schlachter <psychon@znc.in>

This doesn't fix this bug for git/master. What's left is a duplicate of FS#574, so this bug can still be closed.
Comment by Uli Schlachter (psychon) - Monday, 25 June 2012, 09:03 GMT
I bet this is the same problem as seen on this mailing list thread:

http://article.gmane.org/gmane.comp.window-managers.awesome/8972

That commit makes netbeans (urgh, java) work with the focus history.

So the real bug here most likely is that something is focusing gnome panel. Previously this didn't hurt, so most likely offender would be awful.autofocus during a tag switch. The problem now would be that awesome actually remembers this action.
Could someone who can easily reproduce this check if just removing 'require("awful.autofocus")' from rc.lua makes the problem go away?

If we don't come up with a good fix soon, I guess said commit could be reverted in the debian package. However, I don't want to revert that commit upstream. Is there a debian bug report for this?
Comment by Julien Danjou (jd) - Monday, 25 June 2012, 09:06 GMT
The problem is not Debian specific so it would be better to fix it upstream.

There's no bug opened on the Debian side.
Comment by Stefano Zacchiroli (zack) - Monday, 25 June 2012, 09:20 GMT
> Could someone who can easily reproduce this check if just removing 'require("awful.autofocus")' from rc.lua makes the problem go away?

I've tried this and it didn't work for me.

More precisely, to be sure I've tested it right:

- (starting from an installed and running 3.4.11 that does not show the bug)
- I've installed 3.4.12
- commented the above line in my ~/.config/awesome/rc.lua
- restarted awesome
- the problem showed up again

going back to 3.4.11 and restarting awesome goes back to the desired behavior.

I've noticed a difference between 3.4.12 with the line commented and 3.4.12 with the line uncommented though:

- with the line uncommented, switching workspace focuses the panel, but at that point Mod4+j is enough to focus the main window
- with the line commented, Mod4+j is not enough (no matter how many times I do that) to focus the main window; only mouse clicking seems to work

Hope this helps,
Cheers.
Comment by Julien Danjou (jd) - Thursday, 28 June 2012, 12:21 GMT
I've an idea. gnome-panel is a dock so it's never hidden when switching between tags. When switching to another tag, every window gets hidden and loses focus if it had it. All is left is gnome-panel, which receives the focus. So awful.autofocus (or something else) gives it focus. Now it gets into focus history because of the commit c0dffca646c1a02276da510bf3587fb7fad8e0e9 fixing #778 that does not filter it out. When arriving on the new tag, the focus is gave to the latests client in history: gnome-panel.
Comment by Julien Danjou (jd) - Thursday, 28 June 2012, 12:24 GMT
FWIW with gnome-panel running, commenting out awful.autofocus, switching to a tag and coming back shows that no window has the focus (not even gnome-panel actually).
With awful.autofocus, in the same operation, gnome-panel has the focus.
Comment by Uli Schlachter (psychon) - Friday, 29 June 2012, 15:10 GMT
Oh, I misread what Stefano wrote.

So if this is due to awful.autofocus, how come gnome-panel gets focused? autofocus uses the focus history, too. (And if nothing is found in the history, it uses a client which awful.client.focus.filter() likes, which shouldn't be true for gnome-panel)
Focus bugs are evil :-(

Since I dont have any good ideas, let's try the bad ones: Could someone comment out the individual add_signal() calls in awful.autofocus and find the evil one? This happens on tag switch, so I guess the result will be property::selected which doesn't help us figure this out.
Comment by Uli Schlachter (psychon) - Friday, 29 June 2012, 15:22 GMT
Can't reproduce with fbpanel (gnome-panel has a metric ton of dependencies). What is fbpanel doing differently?

Could someone else test if this also happens with fbpanel? If not, I'd like to see some xprop output for gnome-panel to figure out why fbpanel isn't affected.
Comment by Julien Danjou (jd) - Friday, 29 June 2012, 15:32 GMT
Yeah, I can't reproduce either with fbpanel.

I don't see any difference, both dock and focusable.

I think you're going to need gnome-panel.

/me pats Uli
Comment by Heiko Becker (heirecka) - Friday, 06 July 2012, 08:22 GMT
The same happens when using Plasma under awesome. If I kill Plasma windows are automatically focused.
Comment by Sebastian Dörner (sdoerner) - Friday, 06 July 2012, 10:35 GMT
I can confirm that this affects KDE's plasma as well. Attached xprop output for plasma.
Comment by Uli Schlachter (psychon) - Friday, 06 July 2012, 11:03 GMT
Managed to reproduce this with fbpanel. Don't ask me what changed.

I threw a luaL_dostring(L, "print(debug.traceback())"); into the code for "client.focus = foo". This says it is awful.rules which focuses fbpanel.

So patch for the default config:
Removed the "focus = true" from the default rule and instead add a "callback = function(c) if awful.client.focus.filter(c) then client.focus = c end end"

But this still means that the focus history is broken with sticky clients (which is way this turned into a problem instead of a slight annoyance).
Comment by Sebastian Dörner (sdoerner) - Friday, 06 July 2012, 11:34 GMT
Thank you, works for me!
Comment by Uli Schlachter (psychon) - Friday, 06 July 2012, 11:58 GMT
Ok, here is a proper patch for this. It extends awful.rules to call functions for any properties. This seems safe since clients dont have any properties that can be set to functions.

Still, I'd like some review of this patch since it changes semantics in awful.rules. @jd: Ping, what do you think about this patch?
Comment by Sebastian Dörner (sdoerner) - Friday, 06 July 2012, 11:59 GMT
Maybe I was a bit too soon. In certain cases, the bug is still there:

- Go to a tag that has no windows apart from plasma / gnome panel.
- click on the plasma panel. It still seems to be focussed this way (which was probably not the case in earlier versions).
- if you now switch back to a tag with other windows, none of them is focussed. You focus them, but when you switch tags they are again unfocussed.
- This problem persists until you restart awesome.
Comment by Sebastian Dörner (sdoerner) - Friday, 06 July 2012, 11:59 GMT
With "You focus them" I mean "you can click on them to focus"
Comment by Uli Schlachter (psychon) - Friday, 06 July 2012, 12:01 GMT
@sdoerner: Yeah, that's kind-of-expected. This rest of this issue is a duplicate of FS#574. No idea what to do about this, but for now I'm just trying to get rid of "panel gets focus on startup".
Comment by Heiko Becker (heirecka) - Friday, 06 July 2012, 12:07 GMT
Thanks! The attached patch works for me.

Loading...