I've been having this problem for a while back when I had installed current but I figured that it was some problem that was due to some package I had installed that went wrong. However, I found that it was also present after installing Slackware 14.0 from scratch, so I'm guessing this bug is deeper than I thought.

The problem is simple, I type into one window in my first virtual desktop, switch desktops, and whatever window I try to type into, no matter how many times I click to make sure that the window has the focus, will ignore my first keystroke. After that it works perfectly, until I switch desktops again when it will ignore my first keystroke.

This also seems to interfere with xlock when I activate it. If I haven't typed anything in the virtual desktop that I just switched to and selected the lock option from the menu, the screen will go black behind my still visible cursor and then go back to the desktop. Pressing any key and then trying xlock will result in it successfully locking.

Searching around for others who had this problem gave me only one result, in this thread on the arch forums:
https://bbs.archlinux.org/viewtopic.php?pid=1102452
The person appears to have had the same issue and says that it was resolved after an upgrade to Xorg which isn't fixing it for me since everything is as new as it's going to get for a while. Can anyone help point out what might resolve this issue for me?

I use Fluxbox with Current on two computers, and I have not encountered this.

I have a couple of troubleshooting ideas, but they are just off the top of my head.

Open a terminal in two workspaces, then start xev (I think it comes with Slackware). Try switching back and forth between workspaces, typing a couple of characters, and seeing whether xev displays output on the first keypress.

If this is a desktop, try changing out the keyboard and seeing if the problem persists. If you don't have a spare, maybe you could borrow one from a friend for five minutes or so. If it's a laptop, test with an external keyboard (the idea here is to rule out hardware).

This is a strange one. Keep us posted.

It took me a while before the error popped up again but I eventually got it to happen with some fiddling. In xev, when the first keypress is ignored, this is the result:

After that keypress, all the other keypresses output proper events that look like this:

This is on a laptop, so I did as you suggested and tried it with an external keyboard and the result is the same as if I was using the built-in keyboard, so I assume that hardware can be ruled out as the culprit. What else do you suggest that I try?

I have no idea what might be causing this, but I realized this morning that I had omitted one suggestion--boot to a Live CD of something and test under the Live CD. If the problem occurs under the Live CD, that will point the finger at some obscure sort of hardware problem; if it doesn't, then there's something screwy with your software load.

Since you indicate that it took a while to reproduce the error in your testing, give the Live CD a nice long workout.

I don't have this problem. The Arch link seems to suggest that it's an Xorg issue ... but I'm not convinced.

Does it happen with any program or just some programs ?

@frankbell Alright, finally got done with my Live CD testing. I used the GParted Live CD which comes installed with Fluxbox by default, and after extensive testing I did not see the problem come up once. Everything worked as it should, so the problem must lie within Slackware. Any suggestions on what I should try next?

@H_TeXMeX_H This seems to happen with any program that has text input. It's happened with rxvt, xterm, Seamonkey, Google Chrome, Sublime Text, just to name a few, so I don't think it's related to any one program.

A couple of other things. I spent a little more time pin pointing what triggers this and I believe that it's a little more complex than I initially thought. This is the exact process (for me at least) :

1. Open four windows, say some text editors, and place 2 of the windows in the first desktop and 2 of the windows in the second desktop.
2. Type into one window.
3. Shift the focus to the other window.
4. Press Ctrl-F2 to switch to the next desktop.
5. You should notice that the text line in the window is now gone, and will only reappear once you press a key.
6. Type into one of the text editors.
7. Switch focus to the second window.
8. Press Ctrl-F1 to switch to the first desktop.
9. The text line in the window should again be gone.

Note that this will only happen if I use Ctrl-F# to switch desktops, using the arrow switchers at the bottom left to switch desktops does not trigger the problem. Also, simply typing in text alone will not trigger the problem, switching windows after typing and then switching with Ctrl-F# will bring about the problem.

I have also tried deleting my fluxbox config and letting it install the defaults. This didn't fix the problem either.

I don't use the Ctrl keys to switch desktops, that's probably why I couldn't replicate it, I use the mouse wheel.

Did some more searching around and I found that this bug has been reported to the fluxbox devs:
http://sourceforge.net/tracker/?func...98&atid=413960
and on the Debian bug tracker:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612893

Among the posts I was able to find a workaround though I take this from post 67 of the Debian bug report (http://bugs.debian.org/cgi-bin/bugre...?bug=612893#67) :
I left the default Control F# part from the default keys file alone but changed Workspace # to ExecCommand wmctrl -s #.This worked for me and I haven't had any problems as of yet. Marking this thread as solved. Thanks to everyone who helped

For those of you who want to know what the problem in fluxbox might be, see these two posts from the Debian bug report:
http://bugs.debian.org/cgi-bin/bugre...?bug=612893#87
http://bugs.debian.org/cgi-bin/bugre...?bug=612893#92

2 members found this post helpful.

Thanks for the update. I usually use the taskbar to switch desktops, so that must be why I haven't run into this myself.