Version: (using KDE KDE 3.3.0) Installed from: Debian testing/unstable Packages OS: Linux After opening and closing a dialog the window originally focused is not given back the focus again. How to reproduce: Most easy way to reproduce is to use the "Run Command" dialog (Alt+F2). Open it via the shortcut and press ESC to dismiss it. Expected behavior: The window which had the focus before opening the dialog should get it back. Observed behavior: The window which had the focus before opening the dialog doesn't get it back. It seems like no window has the focus. Additional information: When the mouse pointer already is located within the rectangle where the dialog appears before opening it, the behavior is as expected (the original window gets the focus back after dismissing the dialog). When the mouse pointer is located elsewhere, outside of the rectangle which becomes the dialog, the wrong behavior occurs. It also occurs with other dialogs besides "Run Command" but this is the most obvious. When there is no application open the focus also does not go back to the desktop, so its not possible to activate "Run Command" a second time when the wrong behavior occurred.
This bugreport seriously lacks important details, like the focus policy used. It is not possible to reproduce this problem using the default KDE configuration.
You are right, so here additional information regarding the focus policy: I am using "Focus follows mouse". The behavior for the each policy: -Click to focus (default) After dismissing the dialog, no window has focus, one has to actively click the window under the dialog to give it back focus (but I am not sure if this is intended behavior). -Focus follows mouse: as described in initial report -Focus (strictly) under mouse: For these two the problem doesn't exist at all because focus does not switch to the dialog once its opened, when the mouse pointer is outside of the rectangle which becomes the dialog. I can reproduce the behavior with a new user (so using default config) after switching to "Focus follows mouse". I will give more information if you could point me at a specific direction what to check.
This problem seems to be debian-specific, so I suggest you complain there. I cannot reproduce the problem, and I seriously doubt such visible problem would make it unnoticed into KDE3.3.0.
I have more information, maybe it will be reproducible this way: The problem only occurs when using two separate X screens (ServerLayout in XFree config features two screens). When dismissing the dialog on the first screen (as I described) a window on the second one gets the focus instead of the window on the first screen which had it before. The same happens vice versa (opening and dismissing a dialog on the second one,...). XFree version is 4.3.0.1 (Debian 4.3.0.dfsg.1-8 20040928112350). Video card is an Nvidia GF4-Ti with two video outputs. I am using the nvidia kernel drivers with support for multiple separate X screens. I am not using the "TwinView" Xinerama-like feature to extend a single desktop over more than one screen. When using only one screen the problem does not occur, thats probably why you couldn't reproduce it. When using the "TwinView" feature and so having a single desktop over both monitors the problem also does not occur. It occurs only when using two separate screens and so two separate desktops.
i also get the same problems with the same setup. i use 3 monitors in multihead (without xinerama) and after closing a window on one screen the focus will always change to another screen. as far as i found out it will change to the previously selected desktop and then there to the oldest selected window. to clarify: 1. on screen2: open window1 and window2 and window3 2. on screen1: open window3 and window4 3. on screen1: close window4 expected behaviour: focus on screen1, window3 actual behaviour: focus on screen2, window1 this behaviour can be reproduced with combinations of all three desktops. it's the same behaviour with windoze on all three desktops but sometimes (about 1/10th) it selects a random desktop (but always not the one it should). using gentoo-linux: X.Org V6.8.1.902 [ Monitor #1: 1280x1024 ] [ Monitor #2: 1280x1024 ] [ Monitor #3: 1280x1024 ] with kde-3.3.2 focus policy: click to focus (but also happens with other policies)
still the same behaviour in kde 3.4.0 (gentoo) :/
ok another 4 months past - still the same problems with kde 3.4.1 and another strange thing i recognized today: this focus problem only occurs when closing kde apps. if i close a gtk app the focus stays on the same screen. fejf btw: is any developer watching this bugreport because i don't see any response or should i file a new one =?
I had a look at the kwin source a while ago, filling it with debug outputs, but must admit that I did not see any light so far. The only thing I can say for now is that in the case where the error occurs the last thing called is Client::focusInEvent with e->detail == NotifyPointer. In cases where it does work fine the code below with workspace()->allowClientActivation etc. is reached. I cannot find a solution for this without further knowledge but I am there if some developer needs help for testing/further debugging.
Focus only seems to change after a application modal box is dismissed. The focus changes monitor in fact possibly to the equivalent window on the other monitor(?), always the same window anyway. Searching with kate for an unfindable string focus sometimes flicks momentarily to the other monitor, sometimes not. Once there it sometimes sticks, sometimes not. The end result is that the behaviour is seemingly random. No xinerama, No clever focus options.
Further to my previous contribution. If I fire up kate in the secondary display focus also changes to the primary (either display will do). In fact a successful search also causes focus to switch, so the modal box is actually only delaying the inevitable. A red herring really. Konqueror, kedit, kmail all show the same symptoms. I can't get Firefox to do this at all, opening/dismissing the "Save As..." box. I'm using different video adapters for each display, kde 3.4
*** This bug has been confirmed by popular vote. ***
installed kde 3.5 and still the same behaviour like a year and two minor minor versions ago... btw: > The focus changes monitor in fact possibly to the equivalent window on the other monitor(?), always the same window anyway. as i have 3 monitors i can say that it's not always the same screen who gets focus. e.g. i close an app on screen1 than the possibility that screen3 gets focus is about 75%, for screen2 25% ... > I can't get Firefox to do this at all, opening/dismissing the "Save As..." box. same here - but e.g. gimp causes the bug for me. so the problem does not seam to be kde-programs-only related.
I can confirm this behaveiour, to reproduce use multihead non-xinerama-mode, make a html-page with a javascript alert in it, open it in konqueror and then use the alt-tab keys to switch to another window. You will see, that you get to the other screen, not the one you got the alert from javascript.
As to the 'This problem seems to be debian-specific...', I am using gentoo-packages.
*** Bug 114253 has been marked as a duplicate of this bug. ***
*** Bug 132083 has been marked as a duplicate of this bug. ***
As for comment #7, multihead support in KDE has never really been maintained, so I suggest either start using xinerama or trying your luck with fixing the bugs (file kwin/HACKING is a good start and the kwin@kde.org mailing list is the place for any possible further questions).
Confirmed with KDE 3.5.5 under Gentoo Linux with an nVidia card (proprietary drivers). It's particularly annoying when using Krusader to copy/move files. I work around it by binding some keys to a script that uses xwarppointer to bring the cursor back to my screen.
The problem seems to be in events.cpp case FocusIn: if( e->xfocus.window == rootWin() && ( e->xfocus.detail == NotifyDetailNone || e->xfocus.detail == NotifyPointerRoot )) { updateXTime(); // focusToNull() uses qt_x_time, which is old now (FocusIn has no timestamp) Window focus; int revert; XGetInputFocus( qt_xdisplay(), &focus, &revert ); //line changed if( focus == None || focus == PointerRoot ) if ( ( focus == None || focus == PointerRoot ) & false) { //kdWarning( 1212 ) << "X focus set to None/PointerRoot, reseting focus" << endl; Client *c = mostRecentlyActivatedClient(); if( c != NULL ) requestFocus( c, true ); else if( activateNextClient( NULL )) ; // ok, activated else focusToNull(); } } // fall through
sorry, hitted submit accidentally I wanted to say that the line I changed to "solve" it is: if( focus == None || focus == PointerRoot ) to if ( ( focus == None || focus == PointerRoot ) & false) so that it doesn't go into the if. I have NO IDEA about what I'm doing, so the better is that someone knowledged give it a look and provide a good solution
hi? anyone there? I can add that I'm working for a week without that 'if' and all seems to be ok, the focus remains in the active screen. I think that it is just a piece of obsolete code, mostRecentlyActivatedClient seems to look for any window, without care if it is on the current screen or not, and maybe it's a race condition between the code which handles it correctly and this one which made it to seem random.. dunno.
i am... still with the same problem for over 2.5 years now ;) i'll try to remove the if as soon as i get back to my normal pc to test this. But perhaps we should create a new bug report for the current kde version because it may be possible that nobody of the kde cares about bug reports for kde 3.3.0 now... fejf
I think it's rather that nobody cares about bugreports about multihead, as it's (pretty much always) been unmaintained feature. Volunteers are welcome. As for the patch, the change seems to be a workaround, not a proper fix, focus being None or PointerRoot should not usually happen.
Ok but the problem is i tried to debug the root of this for about 3 days without any luck. So I'm not able to provide a proper fix. Only thing i can give is that it seams that this is a race condition because if i use the crystal theme (more cpu usage) this bug happens nearly every time while standard (not so cpu consuming) themes give the error less often. I also got some debug output which didn't give any clues for me... fejf
I would like to have more time, to be a kde contributor sounds great... but no time atm :'( Imao I think there are 2 possibilities here: 1.- The entire piece of code is obsolete and should be removed (my preferred) 2.- There are 2 bugs, one, based on Lubos comment, is making the focus None or PointerRoot with anomaly frequency, and the second in mostRecentlyActivatedClient, which seems to be maintaining a single list of clients without taking care of the client display and current display to select the last active client. And found another bug, while working on display :0.1, some popup windows from konqueror (accept/reject cookie, web server username password) appears on display :0.0, can't tell if is my fault due to removing the if on the FocusIn code... but don't think so.
The work around in #20 works for me, thanks! I can reproduce this problem 100% of the time using Alt-F2 or the delete confirmation dialog in kontact. If the mouse is over where the popoup window will appear the problem does not manifest, otherwise.. I am using FreeBSD, KDE 3.5.8, X.Org 7.3 & the NVidia binary driver.
Hi again, just a question: Where the hell is the kwin source in kdebase-3.97? O_o Before switching to kde4 I wish to know if the workaround has any chance to work. Thanks.
OK, is on kdebase-workspace, sorry.
there have been some multi head related fixes in 4.7. No idea if this issue is fixed, but I am not able to gasp what this bug report is about. So I set to unmaintained as it is about KDE 3. If the issue is still present in a recent version please open a new bug.