Hmm. I've suddenly discovered something new. Don't know if I've seen it before, but the problem seems to be this: When X11 loses focus and regains it, it assumes that the state of the modifiers is unchanged since it last had focus. This is easily demonstrated with an xev and (say) a Terminal window. With the xev window having focus, press a modifer - say shift - and hold it down while clicking on the Terminal window. Release the modifier, click on xev again, and type a regular key. Check the State field in the resulting xev output: 0x1 for the shift key, 0x4 for the control key, 0x5 for both, and so on. You may ask, why would someone do something as convoluted as this? But I think it happens easily. It happened repeatedly to me before I figured it out. I have set up Spaces so I change space using ctrl+alt with arrow keys to move around. That makes it easy for X11 to lose focus while the control key is down. An xterm that believes the control key is down does not behave normally, I can now say with some confidence. I suppose there must be a way for an application to query the state of the modifier keys, without keeping track of keypress/keyrelease events? So that seems to be what X11 must do to, each time it loses and regains focus - so it can adjust its own beliefs about current state. Since I cannot recall stumbling over this before, maybe it used to do that, and this is a regression? I run X11-2.2.1-rc2, Xquartz-1.4.0-apple5, and Ben's quartz-wm. - Harald