Welcome to awesome bug tracking system.

FS#960 - Awesome causes Lyx menu misbehaviour

Attached to Project: awesome
Opened by Sascha (ElkMonsterr) - Tuesday, 07 February 2012, 18:03 GMT
Task Type Bug Report
Category Core
Status Unconfirmed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version git/master
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


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.

Detailed report here:
Follow steps at comment #5 to reproduce.
This task depends upon

Comment by Uli Schlachter (psychon) - Wednesday, 08 February 2012, 17:16 GMT
I got bad news for you: I can't reproduce this either.

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)
Comment by Uli Schlachter (psychon) - Wednesday, 08 February 2012, 17:19 GMT
Oh and before someone asks: Debian amd64 testing, lyx 2.0.2-1
Comment by Sascha (ElkMonsterr) - Thursday, 09 February 2012, 00:06 GMT
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).
Comment by Uli Schlachter (psychon) - Thursday, 09 February 2012, 08:51 GMT
Which exact awesome version are you using?

And for what awesome is doing:

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!
Comment by Sascha (ElkMonsterr) - Thursday, 09 February 2012, 12:12 GMT
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...
Comment by Alexander Yakushev (Alex.yakushev) - Thursday, 09 February 2012, 13:51 GMT
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 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) 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.
Comment by Uli Schlachter (psychon) - Thursday, 09 February 2012, 17:15 GMT
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)
Comment by Sascha (ElkMonsterr) - Thursday, 09 February 2012, 19:17 GMT
I've informed Lyx devs of this bug report and Alexander's discovery.
Comment by Sascha (ElkMonsterr) - Thursday, 26 April 2012, 12:19 GMT
Just to keep you informed: I've opened a bug in the QT project bug tracker, but not a single reaction there for two weeks:

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.