mixu / nwm

Tiling window manager for X11 written in Node.js
http://mixu.net/nwm/
MIT License
789 stars 72 forks source link

Menus are not accessible #24

Closed shaworth closed 9 years ago

shaworth commented 12 years ago

I am attempting to run firefox in a kiosk-like environment. To accomplish this I have implemented the following:


function run_forever(name) {
    var firefox_proc = require('child_process').spawn(name);

    firefox_proc.on('exit', function(code) {
        console.log('Child process exited with code ' + code);
        console.log('Restarting!');
        run_forever(name);
    });

}

// START
nwm.start(function() { 
    run_forever('firefox');
});

Firefox runs as desired, and is fully functional. When I stop firefox [CTRL]+[Q] it is restarted as desired. However, none of the drop-down menus are accessible. I have reproduced this behavior using xephyr on Ubuntu, and on a second machine with GDM configured to run a nwm session.

Thoughts?

mixu commented 12 years ago

Is this with the latest master? I put in quite a few fixes ~ 3 months back and haven't seen this behavior since then.

What are the version numbers for FF, Ubuntu and Node, and the git revision for nwm? nwm.err.log / nwm.log? "Reverting focus change" messages in particular might be of use here.

Basically, menu glitches were caused by the focus stealing prevention, which tries to stop windows from stealing the focus when they are not focused by nwm. This is a notoriously painful problem as apps can misbehave, e.g. http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00013.html

What happens when you add a second window, like an xterm and move the mouse between FF and xterm? It might be that the focus is not set correctly immediately after launch, since in normal use I'll quickly start having more than one window which triggers a bunch of events.

shaworth commented 12 years ago

Evidently this behaviour is tied to having a single X client in the window list. Here is how I arrive at that conclusion:

Environment: Distro: Ubuntu 10.04 LTS Kernel: Linux boomer 2.6.32-41-generic #90-Ubuntu SMP Tue May 22 11:29:51 UTC 2012 x86_64 GNU/Linux XServer: Xephyr as :1 Firefox: 10.0.1

shaworth@boomer:~/source/nwm$ git rev-parse HEAD 15a3454dc9e2735007a0c4331a38d316195734a2

Steps to reproduce

1) Pull master of nwm from git 2) Apply the following patch to nwm-user-sample.js

> nwm.addLayout('tile', layouts.tile);
13,15c14,15
< //nwm.addLayout('tile', layouts.tile);
< //nwm.addLayout('wide', layouts.wide);
< //nwm.addLayout('grid', layouts.grid);
---
> nwm.addLayout('wide', layouts.wide);
> nwm.addLayout('grid', layouts.grid);
186,197d185
< function run_forever(name) {
<   var firefox_proc = require('child_process').spawn(name);
<   
<   firefox_proc.on('exit', function(code) {
<       console.log('Child process exited with code ' + code);
<       console.log('Restarting!');
<       run_forever(name);
<   });
< 
< }
< 
< 
199,201c187
< nwm.start(function() { 
<   run_forever('firefox');
< });
---
> nwm.start(function() { });

3) Launch Xephyr/Xnest/X (Behavior is not X-server specific) 4) Launch nwm 5) Firefox will start automatically, exercise the drop-down menus. 6) Quit firefox (using keyboard shortcuts, or menus) 7) Firefox will re-start, observe that drop-down menus are not accessible.

Steps to confirm that this behaviour does not exist when xterm is running on another workspace. This is 100% reproducible.

Logs are available here: http://www.spaceopera.org/nwm_logs.tar.gz

Shannon

shaworth commented 12 years ago

BTW, the discovery of the 'open xterm in another workspace' workaround make this issue MUCH less critical for me.