Version: unspecified OS: Linux Frequently, while working on something else, kwin spontaneously switches me to the desktop where Thunderbird is running on. I've already have had that problem in KDE 3.5, and then the recommendation was to set "Focus stealing prevention" on the offending app (i.e. Thunderbird). However, now I've already got "Focus stealing prevention" set to "Extreme" both on Thunderbird's "Special Window Settings" and "Special Application Settings", and it still manages to do this. Please fix this. Why are applications even allowed to trigger such obnoxious behaviour in the default config? Reproducible: Sometimes Steps to Reproduce: 1. Start up Thunderbird 2. Switch to a different desktop and work on something else Actual Results: Often, the desktop forcefully switches back to where Thunderbird is running Expected Results: It should just let me continue working on whatever I am working at. This bug is particularly disruptive when typing big amount of text, if you're a fast typist, you lose your input and if your keystrokes happen to mean something for thunderbird (shortcuts), they may cause unwanted side effects.
works for me (4.4.3) notice that mozilla based applications have the "nice" attitude to change WM hints with every release so after updating thunderbird you must re-detect the window from the rule dialog.
Is there any way to set Focus stealing prevention globally? That way, they can change their app name as many times as they want, and they won't be able to mess with my desktops. ... and why on earth is focus stealing even allowed by default?
normally when a window gets mapped, it also gets the focus. in a click-to-focus setup this is convenient, usually what you want and also some sort of de-facto standard (not sure whether it's even part of netwm specs) normally this would not cause a desktop change, but mozilla is just very aggressive in focus grabbing for god knows what reason. as long as the extreme protection (kwin feature) works, this is a clear mozilla bug. you can set the global focus policy in "kcmshell4 kwinoptions", but a global extreme protection is probably not what you want. please confirm that this protection level still works for you.
Yes, I noticed that behaviour, especially with emacsclient, which screws up focus management both when the window appears (gets focus when it otherwise wouldn't), and again when it disappears (random window gets focus, even if mouse is over another window). Fortunately, Focus-stealing-prevention is fortunately able to fix it (even at level "Low" => good) Why would grabbing the focus force a desktop change? Shouldn't it work the other way round: being on a different desktop should IMHO _prevent_ a focus change. I just found the issue with Thunderbird: its various windows register as different applications, and so far I've always tried to set focus stealing prevention on its main window. Once I set it on its pop-up window as well, the problem went away. I actually need to set it on *both* the popup window, and the main window, only one of them is not enough. However, I don't need "Extreme". "Low" is enough (... but needs to be set on both windows...). With all this, I have to wonder: why are application even allowed to "be aggressive in focus grabbing". Couldn't this be mis-used by keyloggers and other malicious applications? I can understand why an application might want to "hold on" to focus (ask not to lose it if it already has it) in order to protect itself against keyloggers, but an app should never be allowed to yank focus away from another app, if it doesn't already have it. This is just asking for trouble.
"low" is the default value.
This is weird, I assumed it was "none"... Or maybe some previous upgrade screwed it up for me? When I tried to fix my global default using kcmshell4 kwinoptions, I noticed 2 things: 1. Focus stealing prevention level was "Medium" (!) (Not "None", and not "Low" either) 2. It didn't let me change it, as it was greyed out in their. So I'm a little bit confused now how this stuff is supposed to work...
it's greyed out because you likely use "focus (strictly) under mouse" and this usually doesn't require a focus protection (you don't want to pretect the focus but mozillas broken desktop switching) therefore "low" wasn't even activated for you and i'm not even sure whether the global option will apply in this focus model (as it's apparently supposed to be medium atm.) -> you'll have to stay with the window specific workaround system
While in theory "focus (strictly) under mouse" doesn't require any protection, in practice it does, even without thunderbird's desktop yanking case. Indeed, without setting protection to (at least) low for emacsclient, it will very often give focus to emacsclient even if the mouse is nowhere near it. Also, when Thunderbird yanks desktops, what call does it exactly perform that trigger this? What should I report on the Thunderbird bug-tracker? Is there actually an X call "switch desktop to me", or is this a side-effect of something else?
don't know about emacs, but i've not encountered a focus violation otherwise (eg. i've a runner that overrides the focus policy, raises and requests activation) in fact, there's a way to force a window to be active and entirely bypassing the WM, but it's meant for pagers etc. and must not be used by normal clients. so this would be an emacs bug. the current desktop is (more or less) altered by setting _NET_CURRENT_DESKTOP on the root window, the toolkits usually provide functions for this (like KWindowSystem::setCurrentDesktop(int)) however, i _guess_ in this case it's the side effect of forcefully taking the focus. hint: try "focus follows mouse", it's more configurable and therefore allows focus protection as well
>in fact, there's a way to force a window to be active and entirely bypassing > the WM Sounds bad... > the current desktop is (more or less) altered by setting _NET_CURRENT_DESKTOP > on the root window, the toolkits usually provide functions for this (like > KWindowSystem::setCurrentDesktop(int)) Is there a way to block this for normal apps (I understand that pagers need it, of course... maybe pagers, taskbars and similar widgets could be "authenticated" in some way, in order to make sure that normal applications don't abuse such management APIs)? > however, i _guess_ in this case it's the side effect of forcefully taking the > focus. As far as I understand you, there is more than one way of forcefully taking the focus. What are these, and what (legitimate) purpose do they serve? And why are there so many of these methods? The thing is, if such a "feature" is present, it will get abused, and it serves no legitimate purpose (or what purpose would that be?). Locking/keeping the focus, I can understand (protection against snooping), but taking it away from some other app is just rude. If an application needs the user's attention, it should flash its icon (or its outline in the pager), but not just steal the focus. > hint: try "focus follows mouse", it's more configurable and therefore allows > focus protection as well If i use "focus follows mouse", the emacsclient problem actually gets *much* worse, and now seems to affect _all_ applications, including xterm. In order to make it go away again, I have to set xterm's "Focus stealing prevention" to "High", which unfortunately also has the side effecting of making xterm's window pop under existing windows, instead of on top. Not good.
> > the current desktop is (more or less) altered by setting > > _NET_CURRENT_DESKTOP on the root window, the toolkits usually provide > > functions for this (like KWindowSystem::setCurrentDesktop(int)) > > Is there a way to block this for normal apps (I understand that pagers need > it, of course... maybe pagers, taskbars and similar widgets could be > "authenticated" in some way, in order to make sure that normal applications > don't abuse such management APIs)? Authentication in an open source environment is hardly possible. If all sources are openly available it's always possible for a bad application to circumvent the protection (by e.g. calling itself "plasma" or fetching the private key from svn). The only possible way is, that all applications behave. E.g. in the case of Thunderbird, just open a bug report and explain why they do things they shouldn't do, so that the bug will be fixed.
While it would be difficult or even impossible to lock out the truly malicious apps, there are quite a number of ways to catch at least the careless or misinformed. 1. Clearly document that such calls are not intended for "normal" applications. If there already are such written rules (RFCs, ...), what are their references? 2. Do not use normal X protocol for such calls, but some KDE-specific transport. 3. Use a key, or include a version number that changes on every minor upgrade to KDE. That will send a clear message that this is a KDE-internal API, and not intended for outside consumption. Even your suggestion of only allowing applications called "plasma" such access would help, because it would clearly establish malicious intent if somebody else would abuse that name. Somehow, I cannot imagine that Thunderbird would stoop that low.
Problem reported to mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=569409
(In reply to comment #12) > 1. Clearly document that such calls are not intended for "normal" applications. The KWindowSystem API (providing an implementation for this call) clearly does so. > 2. Do not use normal X protocol for such calls, but some KDE-specific > transport. No option. Eg. awn has to work with kwin as well as with compiz, etc. So do the various desktop, other panels, pagers... this is why there're fdo specs. > 3. Use a key, or include a version number that changes on every minor upgrade > to KDE. That will send a clear message that this is a KDE-internal API, and not > intended for outside consumption. It's not KDE internal API. (thunderbird does certainly not link kdelibs) > Even your suggestion of only allowing applications called "plasma" such access > would help This is a) not possible (the X server notifies about the event, not who triggered it) b) a strategically stupid idea: Enforcing the use of specific software will lead to wars and segregation. ( => "Sorry, no GIMP in a KDE environment... really not. KDE sucks, get GNOME") Whitelists are no option - this is not Apple (at least last time i checked ;-) However you actually have to set a specific source type on the event data (hinting this is some sort of window managing tool), that will most unlikely hold for thunderbird (if they do it this way, i don't know anything about thunderbird/XUL code)
> The KWindowSystem API (providing an implementation for this call) clearly does so. Good. > No option. Eg. awn has to work with kwin as well as with compiz, etc. What is awn? So I could theoretically use a page intended for Gnome, and put that into my KDE plasma? Woot, I didn't even know that... :-) > It's not KDE internal API. (thunderbird does certainly not link kdelibs) Well, I meant an API defined in KWindowSystem API, not necessarily one provided in kdelibs. > Even your suggestion of only allowing applications called "plasma" such access This was actually Martin's suggestion :-) > would help > a) not possible (the X server notifies about the event, not who triggered it) ... oops, too bad :-( > b) a strategically stupid idea: > Enforcing the use of specific software will lead to wars and segregation. ( => > Sorry, no GIMP in a KDE environment... Actually, if Gimp tried to pass itself off as a desktop accessory and tried similar funny tricks, I'd be as unhappy about the Gimp as I am now about Thunderbird... Such behavior still wouldn't warrant outright banning it, but mapping those calls to no-ops for it would certainly be in order. And if on the other hand, Gimp _doesn't_ try to masquerade as a desktop accessory how would it be impacted by any such black/whitelist?
(In reply to comment #15) > What is awn? a docker, http://wiki.awn-project.org/ > Well, I meant an API defined in KWindowSystem API, not necessarily one provided in kdelibs. KWindowSystem is part of kdelibs. It's not the windowmanager but provides functions to deal with windows. > Actually, if Gimp tried to pass itself off as a desktop accessory and tried... i meant that as drastic (and supposed to be funny) result of such whitelisting strategy. (sorry) if kwin ruled in or out certains applications, so could a major tool like TheGimp just refuse to start in a KDE environment. (and a whitelist would always accidently block some valid tool and cast a bad light on kde)
> KWindowSystem is part of kdelibs. It's not the windowmanager but provides > functions to deal with windows. But then, how can thunderbird use KWindowSystem if it doesn't link with kdelibs? > i meant that as drastic (and supposed to be funny) result of such whitelisting strategy. (sorry) No problem. In a text-only medium, it is sometimes difficult to tell humor from genuine misunderstanding :-) > and a whitelist would always accidently block some valid tool and cast a bad light on kde Maybe, there could be some UI to manually add "forgotten" dockers, taskbars and pagers to the whitelist. That would lessen the impact of any accidental omission, while still preserving safety (in case of abuse, the user would wonder why he would need to add a mail program or a drawing program into the list of allowed desktop management softwares)
this starts to get really OT, please mail kwin@kde.org or me directly if you want to go on with such discussion (In reply to comment #17) > But then, how can thunderbird use KWindowSystem if it doesn't link with > kdelibs? the function in KWindowSystem only triggers an X event, you can do that directly, just linking libX11 as well. > Maybe, there could be some UI to manually add "forgotten" dockers, taskbars and pagers to the whitelist. Aside that this is still not possible (read above... you get no -and esp. no reliable- idea about the triggering process) you'd expect users to determine specific processes and extend a whitelist because some applications are abusing system functions? Either this is a (known and fixable) bug in the client - then it needs to be fixed, or the application is abusing the functionality by intend, then it will just lie harder. Ask users to work around such abuse cannot be a protocol design at all, suck it :-) Thunderbird is buggy and therefore kwin provides a structure to (temporarily) work around buggy clients. Do so and ask thunderbird devs to please fix their application - or use another mailer, there're dozens. (mutt & pine, sylpheed & claws, mulberry and of course kmail - to name just a few)