An alleged race condition on client focus about awesome HOT 7 CLOSED

This may or may not be in the same bag as #130 . In any case, someone need to investigate the client initialization code to be sure it is reproducible from run to run and behave in a sensible way.

To mitigate your issue, there is a request:: signal API. Take a look at "request::activate" to implement your own handler. I also had some issues with "transient for" popups initialization order being random, but I have "fixed" this by handling that event myself (in Tyrannical).

from awesome.

@Elv13 Thanks. I forgot to mention that the issue I reported has nothing to do with custom handlers. I can reproduce it with a default rc.lua.

from awesome.

Ok, A correction (sorry). The client DOES get focus. I was only looking at the border color to tell if it has focus or not.... silly me. The bug seems to be that after #118, the border color is not properly set from within a focus signal.

There are still things I don't understand in the sequence of calls I reported before, though.

from awesome.

it looks similar to problem i reported in comments -- 90fde13#commitcomment-9423747

it was fixed in one of the later commits but got broken again almost at the same time as i faced that #130 issue

from awesome.

Yes! @psychon comment in there (90fde13#commitcomment-9424536) is very helpful. In particular it explains why I was seeing two calls to client_focus. Also explains the problem I have!

After a quick test, it turns out the same race between focus handler and rule application happens here!

This still needs a fix. It is odd that rules sometimes win over the focus handler, and sometimes do not.

from awesome.

#116 might help here.

from awesome.

2328b57 fixed this for me. Thanks!

from awesome.