Version: unspecified (using KDE 4.7.3) OS: Linux Sometimes if you switch between applications, the window button is not marked as pressed correctly. I am not sure if it's just a display problem or if the focus is not set correctly. It mainly occurs while switching between GTK/xulrunner apps like Firefox/Thunderbird. I have never noticed this while switching between KDE only apps. Reproducible: Sometimes Steps to Reproduce: You have to switch fast between GTK apps or GTK and QT apps in order to see this behavior. Actual Results: button is not marked as pressed, focus is not set correctly Expected Results: butten is marked as pressed, focus is set correctly
sounds like an issue with the apps, perhaps doing something unfortunate with their window management. will let the kwin people decide ...
If the appliation doesn't have the keyboard focus, the "window button" ("taskbar entry") is not supposed to represent an active client, that's ok. How do you change the focus to those applications (clicking them, the taskbar entry, using alt+tab, etc.) Does it also happen with other ways to change the focus? Do the applications in question keep some open dialogs around at such times?
I click the entries on the taskbar. No additional dialogs are open. I have also retested it again and noticed that this also happens with KDE applications only. I can reproduce this more often if I minimize windows in between.
I have tested to select a menu from one of these applications (where the button is not marked as pressed) with the keyboard shortcut, and it worked. So I guess the keyboard focus is correct?
Also this kind of 'locked' application can be selected (brought to front) but not minimized/restored from the taskbar. I think you can emulate this by switching as gone wild between windows using the task manager in panel. It still happens more often with apps like firefox but is not limited to them. It also happens more often if you got more than two apps open.
Yes, means the focus is correctly applied but the taskbar (or libtaskbar) messes up states internally. Also see bugs #278869 and #246838 - could be a duplicate of either (depending on your local setup)
*** This bug has been marked as a duplicate of bug 278869 ***