Version: (using KDE 4.2.1) OS: Linux Installed from: Fedora RPMs After closing an emacsclient window using the keyboard (C-x #), focus goes to main emacs window, even if mouse cursor is nowhere near it. In order to get the focus back in sync with the mouse, I have to leave and re-enter the current window. Sometimes focus is also screwed up when _opening_ emacsclient (it fails to get focus, even though the mouse is in it). However, this is much more rare. I've seen to remember having seen the same behaviour with other applications, but with emacsclient it seems to be most easily reproducible (almost always). This happens with "Focus follows mouse". With "Focus Under Mouse" and "Focus Stricly Under Mouse", it doesn't happen, but when I chose one of these, I lose the possibility to set "Focus stealing prevention level" which I need in order to prevent third-party applications from randomly switching desktops on me.
Problem can be worked around by setting "Focus stealing prevention" to a level of at least "Low". It would however be preferable if as a user I had the choice of setting a high enough default level "Focus stealing prevention" (but 'kcmshell4 kwinoptions' doesn't let me, if I have "Focus under mouse"). That way, I could protect myself generally, and only whitelist the elements that have a legitimate need to manage focus and virtual desktop.
actually you _can_ set a global rule. the global stealing prevention is ignored in the plain hoveractivation modes, but you can add a new rule (the rule system takes place) with "unimportant" window class/role/type (the first two tabs), forcing a protection for all windows (the rule applies globally)
This is interesting. But does this work with "exceptions". Say, I set "Focus Stealing Prevention" to "Extreme" for every window, but want to make an exception for the "Window List" Widget where it would be "Medium" instead. Would the system correctly know that the exception should override the general rule? And btw, how do I find out the relevant window class/role/type for the "Window List" widget? As this isn't an application with a window, I can't just click on its titlebar and go into Advanced->SpecialApplicationSettings... Interestingly enough, other plasma widgets, such as the pager and the taskbar do work correctly even with "focus stealing prevention" set to "Extreme" globally! In the meantime, I did some additional research and found that: - firefox is affected as well, and in a much worse way, because it can be triggered by a web page by just popping up a javascript alert()! This has the advantage of being much easier to debug (no need to restart firefox, just load a webpage which pops up an alert in a setTimeout() handler instead) - using xmon, I tried to debug the X message exchanges between Firefox and the X server, and I suspect that the problem happens in a changeProperty request of WM_HINTS. Could also be a ChangeWindowAttribute. Unfortunately, xmond's "block request" feature doesn't work as expected, so it's hard to find out experimentally which exact request "does" it. However: one thing is sure: there are no GrabKeyboard, SetInputFocus, etc. requests. The only Grab* there is are a couple of GrabServer calls, but these look benign (used more like a mutex, I suspect). Xmon seems to have been unmaintained since before the 90's, do you happen to know another X protocol debugger which is more recent and better maintained? Thanks
(In reply to comment #3) > But does this work with "exceptions". Say, I set "Focus Stealing Prevention" to afaik no, you'll have to add a (negating) regexp match in this case > I can't just click on its titlebar and go into Advanced->SpecialApplicationSettings... "kcmshell4 kwinrules" / "New..." this is related to the oterh bug: > Interestingly enough, other plasma widgets, such as the pager and the taskbar > do work correctly even with "focus stealing prevention" set to "Extreme" > globally! the WM tool call is applied regardless of any focus protection level. i just tried "focus under mouse" and w/o protection the desktop is actually changed on mapping (any) window immediately. so there's no protection in this regard. i guess changing desktops is a kwin bug in this context - mozillas aggressive focus pulling on low protection and click-to-focus is another beast. (it's likely switching the VD explicitly before calling focus) this got a little messed up (i wasn't aware of your focus model in the beginning and the mozilla bug is known, sorry) > experimentally which exact request "does" it. However: one thing is sure: there > are no GrabKeyboard, SetInputFocus, etc. requests. The only Grab* there is are input grabs are unrelated. this just means a client will receive input events exclusively > do you happen to know another X protocol debugger which is more recent and better maintained? Sorry, no.
> the WM tool call is applied regardless of any focus protection level. But then how come we have this problem at all? Why isn't focus protection level "Extreme" then by default, if WM tool calls are applied regardless? Earlier in this discussion, you said that there was no reliable/acceptable way how the WM could tell its tools apart from other applications, so now which is it? Also, the weird thing is that although the pager and the taskbar widgets work despite "extrem" focus protection level (good), the "window list" widget *does* get impacted. Or are there even several levels of "WM tool call", some of which are affected by focus protection level, and some which aren't? > i just tried "focus under mouse" and w/o protection the desktop is actually > changed on mapping (any) window immediately. so there's no protection in this > regard. > i guess changing desktops is a kwin bug in this context Indeed... except for the case of emacsclient, which seems to do it also with "focus strictly under mouse". But emacsclient is doing weird stuff... on my kubuntu box at home, it is actually warping the mouse pointer to a different spot to get focus that way! > mozillas aggressive > focus pulling on low protection and click-to-focus is another beast. (it's > likely switching the VD explicitly before calling focus) Any idea how to spot this easily in xmon? > this got a little messed up (i wasn't aware of your focus model in the > beginning and the mozilla bug is known, sorry) Good to know it's known, hopefully it will get fixed. > input grabs are unrelated. this just means a client will receive input events > exclusively Ok, I'm not so familiar with all the different X calls, so I'd appreciate a couple of hints what to look for... And isn't "focus" basically a fancy way of saying that a client will receive all input events of type "keyboard"?
the extreme focus protection will cause windows to not raise or get focus on mapping. this is likely not what joe user (including yourself) expects/wants. also for hover focus models, focus protection makes no sense at all. the VD should maybe just not switched on window maps. this may be bug or intention. don't know. what i said on bug #240332, comment 18 is that if(f) a client uses the forcefull way to gain focus, there's no way to figure who called the activation and whether it's really a WM tool or not. I do not even see any relation to the focus protection level. the window list widget would have to use the forcefull activation. that's matter on whether it considers itself as a WM on one level with a pager or not. > Any idea how to spot this easily in xmon? No. > Good to know it's known, hopefully it will get fixed. No ide, but i don't have the impression the mozilla team intends to. (this is a really old issue) > And isn't "focus" basically a fancy way of saying that a client will receive all input events of type "keyboard"? Yes, but not exclusively. (It's easier to understand with the mouse. Popups grab the pointer so they're the only ones to receive all mouse events anywhere. Therefore they can close themselves when you click outside)
> the extreme focus protection will cause windows to not raise or get focus on > mapping. Yes, I noticed that. Is this by intent (in order to avoid windows from getting focus by popping up under the mouse pointer?) or is it a side effect of something else? > the VD > should maybe just not switched on window maps. this may be bug or intention. > don't know. If it is intentional, let me point out that this would indeed be annoying... (but fortunately rare) > is that if(f) a client uses the > forcefull way to gain focus, there's no way to figure who called the > activation and whether it's really a WM tool or not. I do not even see any > relation to the focus protection level. I get the impression that this changes every time that I bring up a new element to the discussion. Maybe the easiest would be to enumerate the (common) ways how an application could force focus, and say for each of these ways: 1. Whether it is affected by focus protection level (and which level) 2. Whether it is possible to find out whether it was a WM tool or not. Obviously some WM tool manage to set focus even when focus protection level is set to high. This raises 2 remarks: 1. If a high focus protection level doesn't interfere with WM tools, why did you bring up WM tools in the first place? ( in bug #240332, comment 9 ) 2. If on the other hand the WM cannot tell which request came from a WM tool, and which one came from an app, couldn't a malicious or careless app also use the same APIs that WMs use and that still "work" on high focus protection levels? And how likely is it that a careless or clueless app would do this accidentally (we're speaking about respectable mail programs and editors here after all, not about bonzai-buddy-like trojans...)? Sorry, all this is way confusing, and somehow I get the impression that it is full of contradictions... I just hope that all this is not a case of "Windows has a similarly annoying quirk, and we have to be like Windows if we want to win the desktop" (which would be weird, as windows doesn't even normally have virtual desktops, but you never know...) > the window list widget would have to use the forcefull activation. that's > matter on whether it considers itself as a WM on one level with a pager or > not. ... and is there any mechanism in place (or even possible) to make sure that such activation is *only* used by WM tools (and not by apps such as thunderbird...). Or is it all just on a voluntary basis?
(In reply to comment #7) > Yes, I noticed that. Is this by intent yes (it's the "extreme" way to handle things) > I get the impression that this changes every time that I bring up a new element > to the discussion. that impression is wrong. > Maybe the easiest would be to enumerate the (common) ways > how an application could force focus, and say for each of these ways: there's _one_ way to activate a client bypassing all WM checks. That is to claim being a WM tool (eg. pager) and send a client message to the server. (check KWindowSystem::forceActiveWindow() for an implementation) Every client can send such message and the WM can not reliably check which client emitted it or even match it's commandline against some whitelist. (technically. aside whitelisting is no good idea anyway. we had this.) I hope, this was clear enough. > 1. If a high focus protection level doesn't interfere with WM tools, why did > you bring up WM tools in the first place? ( in bug #240332, comment 9 ) i did not bring up WM tools but the fact that a client can forcefully take focus. the -other- bug report could be triggered by such invalid focus action, esp. after your claim in comment 8 about emacs doing so. (we should btw. really cross discuss other bugs.) > 2. If on the other hand the WM cannot tell which request came from a WM tool, > and which one came from an app, couldn't a malicious or careless app also use > the same APIs that WMs use and that still "work" on high focus protection > levels? Yes. That's why you said "malicious" and "careless". > And how likely is it that a careless or clueless app would do this > accidentally (we're speaking about respectable mail programs and editors here > after all, not about bonzai-buddy-like trojans...)? As likely as passing the wrong parameter to a ClientMessage event. > ... and is there any mechanism in place (or even possible) to make sure that No and no. Who and how should decide what's a valid WM tool. Please don't start trolling about security regarding this. If there's malicious SW on your system you're screwed. Period. A keylogger (other bug, comment 4) would certainly not take focus (the user would notice that there's sth. wrong) but just register itself to the keyevent listeners for all clients. Also there's no way to detect the intentions of such monitoring client.
> there's _one_ way to activate a client bypassing all WM checks. Good. And how many ways are there in total to claim focus (including those that *don't* bypass WM checks), and what is their intended use? > I hope, this was clear enough. No, unfortunately, it isn't. I'm still trying to understand which ways are supposed to be caught by focus stealing prevention, and what their intended use case is. For the moment, the only example of intended use I got is WM tools (pagers, taskbars etc), but their calls aren't affected by focus stealing at all. Thunderbird's call (fortunately) is being affected by focus stealing, so it must be a different call. What is it (or what could it be, if there are several ways matching the observations), and what would its legitimate purpose be? > As likely as passing the wrong parameter to a ClientMessage event. Oops, that sounds bad. So it's really like there is a claimFocus(int level) call, where confusing 2 levels with each other would result in bad behaviour. And not something like completely completely different apis (like app_getFocus() versus getMagicLowLevelHandle().getObscureHandle().getFocusRaw())
on the NETWM level there's actually just this one client message to claim *activation* _explicitly_ the source parameter ("what requests this activation") then causes the force vs. not force handling.* the focus protection does not affect the messages indicating a WM Tool source. nothing (NOTHING) but such tools should this forcefully take the focus. there's however a difference between claiming active state and input focus, latter is done via XSetInputFocus and implicitly requires activation - this is what applications are usually supposed to do as it is what they actually want. (aside this there's implicit actiavtion by mapping, ie. showing windows and oc. the user input way, like clicking or pointing a window) there's a pretty extensive explanation in kdebase/workspace/kwin/activation.cpp plase notice that the various attempts to prevent applications from stealing the focus are WM internal "features" *the various toolkits oc abstract this message and for KDE you differ between activateWindow() and forceActiveWindow()
> on the NETWM level there's actually just this one client message to claim > *activation* _explicitly_ If there is only one client message to claim activation, why are there so many different levels of focus prevention ("low", "medium", "high")? > there's however a difference between claiming active state and input focus, > latter is done via XSetInputFocus and implicitly requires activation - this is > what applications are usually supposed to do as it is what they actually want. What is the difference in purpose between asking for activation and asking for focus? And why would a (non WM) application ever explicitly ask for focus (rather than wait until it is given focus)
(In reply to comment #11) > If there is only one client message to claim activation, why are there so many > different levels of focus prevention ("low", "medium", "high")? heuristics dealing with related windows, window types, time stamps... > What is the difference in purpose between asking for activation and asking for > focus? a window can be active (iff even only as placeholder) but not interested in the input focus (which is then nowhere and thus does not have to be "stolen" but is free for another window to safely request focus and activation...) > And why would a (non WM) application ever explicitly ask for focus (rather than > wait until it is given focus) client internal logics. you could eg. pick a tool in a toolwindow activating some texediting in the mainwindow. so while you clicked the toolwindow the doc window shall get the input focus. also X11 itself does not include the concept of a window manager. there could be setups where only one application runs that handles input focus of multiple windows by a client internal concept. (think of a pointerless terminal) X11 was surprisingly not (exclusively) designed to run windows-a-like homeuser desktop environments :-P
>> If there is only one client message to claim activation, why are there so many >> different levels of focus prevention ("low", "medium", "high")? >heuristics dealing with related windows, window types, time stamps... I see. So which level will completely block this one client message, under any (timing, window relationship, etc.) circumstances? >> And why would a (non WM) application ever explicitly ask for focus (rather than >> wait until it is given focus) > client internal logics. I see. But wouldn't it more logical, for that case, to do just the opposite: the window which *has* the focus instead yields (gives) it to the one who should have it? Or have a different call, which would only work if the window currently having focus does indeed belong to the same app... > think of a pointerless terminal In that case, wouldn't there still be one application which would play the role of a window manager?
> So which level will completely block this one client message, under any circumstances? "Extreme" (requires explicit user intervention) > But wouldn't it more logical, ... No. Think of docks. They usually don't get focus at all, but a lineedit inside might want it when being clicked. > wouldn't there still be one application which would play the role of a window manager? Yes, in doubt the running one. Still it has to tell the X server when to redirect input to which window. (the presence of a pointer does actually not matter, i hoped to be able to stree the requirement of a general API for all clients to set the input focus) One note: you opened at least three bugs on the same topic. that's not too helpfull. Please collect your issues, proposals and wishes regarding this in _one_ (new) bug/wish and close the others. Thank you.
Isn't this bug a duplicate of bug #159989 ?
yupp. though, while i cannot really estimate the intentions of focusfollowsmouse, i'm under the impression that this is "intended" (or rather a result of the intended design to only pass focus on explicit enter/leave events) - what also causes some of the other issues you crossed today in this regard... like the the misbehaviour while the pointer is grabbed by a popup etc... =\ *** This bug has been marked as a duplicate of bug 159989 ***