Details

It seems Awesome causes buggy behaviour in Lyx. Something prevents the input focus from being set back to Lyx's text input area when certain actions are performed in the menu using keyboard only (see below).
Doesn't happen on the same system with Xfce. Neither Lyx devs nor Arch Linux forum members could reproduce the issue on their non-Awesome systems.

Also, the WM doesn't really have anything to do with the app-internal input focus. It just controls which top-level window has the focus (and menus are done in a magic way which the WM can't influence, too)

Man, this is getting annoying... is there any way I can further investigate the issue? Does Awesome actually touch window toolkit stuff anywhere (i.e., setting focus to menus etc), is there some point where they interact with or depend on each other? I'll start some heavy thesis writing soon, and this thing will certainly break my mouse-less workflow... :(
And before someone asks: I have double-triple-quadro-checked this. ;) And it occurs on two fully independent computers, their only things in common being the owner (well, and both running an (independently administrated) up-to-date Arch 64).

When a menu is opened, an "override redirect" window is used. That means that the WM doesn't get any notification of this and that this window has to handle everything itself. When the menu closes, the last window which had the focus automatically gets it back.
For what the WM has to do with windows: It only sees toplevel windows (which it e.g. lists in the tasklist). When it wants to focus a window, it can just focus the whole window. All the stuff internal to the window (including the menu bar when no menu is opened) isn't seen by the WM nor by the X11 server. The WM doesn't know about this and can't focus this.

I tested this with awesome git/master, could some 3.4 user do a quick test with lyx? This really does not take long to test!

awesome v3.4-619-ge052bd9 (Closing In)
• Build: Feb 8 2012 03:28:51 for x86_64 by gcc version 4.6.2 (root@kueken)
• D-Bus support: ✔
Before, I was using a build from November 2011 though (did an update to verify that issue still exists in latest git).
I've also checked with the default rc.lua now, just to be sure none of my custom config code is doing something wrong - but no, same thing happens.

I guess I have to get used to checking the menu for the hovered effect it has when focused. If so, I can press Alt to un-focus it (no mouse required contrary to what I suggested before). It's just that when you want to type and you're really concentrated, every small disruptive factor becomes really annoying...

I was able to reproduce it, version 3.4-617-gc6e9208 (Jan 27 2012). Everything is just like Sascha stated in the Lyx ticket.

The bad news is that I also reproduced it in dwm and without any WM at all (started xterm in Xephyr and run Lyx from there). Seems like the bug is in X.org or it is Lyx wrongfully doing the refocus (much likely).

Another interesting moment is that if you just press Alt and navigate to the top level menu with arrows (no Alt-I or something) the bug won't reproduce.

If the bug doesn't show up in XFCE/Gnome/etc than it is probably these DEs somehow messing with the in-window elements and that way "fixing" the bug. But It occurs to me that if:
1) X.org has this bug by default (without any WMs)
2) Other applications do not have such a bug
Then the responsibility for fixing this lays completely on the Lyx developers' shoulders.

So you guys are using git/master, too? Whoa. That already rules out non-reparenting WMs (but it still does happen in dwm....).

Another update on the focus thing: I think that qt doesn't actually create subwindows. It just has a single, toplevel window and it draws everything directly into that. This makes a bug in the Xserver even more unlikely.
However, this also means that other WMs can't really mess with the in-window elements because there are just pixels, no more windows.

Could someone ping some LyX devs? Hopefully one of them can reproduce without any WM at all. If not, I'd be curious for some help around their source code. Perhaps they are doing some unusual magic with their menus which confuses qt? Perhaps some magic with the keybindings? (But I guess no one will step and say "oh yeah, we are doing this hack here and obviously it's wrong)

Also, I found out that one can work around the bug in a pretty simple way. The single important step is to press ALT separately to focus the menu bar (instead of directly selecting the wished menu, like ALT+i for "Insert" menu), then use letter or arrow keys to navigate.