Version: (using KDE 4.2.1) OS: Linux Installed from: Fedora RPMs Occasionally, KDE switches to a different virtual desktop seemingly on its own, without explicit user request. I have a suspicion that there is an API in place which allows applications to request this if they want to attract the user's attention. Well it sure does attract attention, but personally, I find such behavior highly disruptive and potentially a security problem. Indeed, when it happens while entering a password, that password may end up in the wrong place, or be clearly displayed on the screen. When it happens while demoing something to a colleague or a customer, it will not only disrupt the demo, but might also accidentally expose confidential or private data present on the desktop being switched to. A more acceptable way of getting attention might be to flash the application's outline in the pager applet. That would be visible enough that the user notices it, but without forcefully interrupting his work flow elsewhere. Is there a possibility to reliably switch off this desktop switching behavior (without side effects elsewhere...), and only allow a short list of applications and widgets to mess with desktop choice. Obviously the pager would need to have the power to switch desktops, and the task bar and the window list button. But no (or few) other applications should have this power. There is the "Focus stealing prevention level" which seemed to help a little bit in KDE3, but in KDE4 it is greyed out :-( And in KDE3, it had the unfortunate side effect of making dialog boxes popping _under_ the main window of applications (thus hiding them) rather than on top, as they should. Well, technically dialog boxes "could" steal focus if they were unfortunate enough to pop up right under the mouse, but an "easy" way to avoid this would be to tweak the placement algorithm that the box would actively avoid the exact location of mouse cursor (pop up _near_ cursor, but not _under_ it. Unless it is too big to fit, of course). With such an algorithm, dialog boxes would be close to the cursor (if user wants to use them), but without disrupting current workflow (if user only wants to handle them later). This problem is not a new problem. It already happened in KDE 3, but is still present in KDE 4.2.1
It's still possible to change focus stealing prevention. Please change your focus-follows-mouse-settings.
Indeed, if I change to "Focus Follows Mouse", I can set Focus stealing prevention level. The level "Normal" now seems to be enough to prevent this desktop hijacking behavior, while still making dialog boxes pop up before app windows, rather than behind (as it happened in KDE3). Good. However, once I switch my focus policy back to "Focus strictly under Mouse", the "Focus stealing prevention level" that I chose is getting ignored, and my desktops are again hijacked. Even though it is still set to Normal. What's going on here? Thanks
(In reply to comment #2) > However, once I switch my focus policy back to "Focus strictly under Mouse", > the "Focus stealing prevention level" that I chose is getting ignored, and my > desktops are again hijacked. Even though it is still set to Normal. How should a focus stealing prevent work if always the window under the mouse has the focus? Is it perhaps possible that you focus the plasma desktop and use the mouse wheel. That'll explain the changing of desktop
> How should a focus stealing prevent work if always the window under the mouse > has the focus? I dunno... maybe by disabling all the API calls that might hijack desktops? > Is it perhaps possible that you focus the plasma desktop and use the mouse wheel. No. It happens while browsing, while editing source in my Emacs, with the mouse far away from the pager... > That'll explain the changing of desktop No, it seems to be thunderbird causing it (this time) when its imap server becomes unreachable. However, why thunderbird should even have the power to do this, no matter what the circumstances, is a mystery to me.
So it's once more a Mozilla application causing such behaviour (why am I again not surprised). I guess it's the intended behaviour by Mozilla that the application receives the focus when they think the user has to react. Of course it would be better that the application demands attention instead trying to get the focus. Please report this to the Mozilla devs. Thanks.
While I agree that the application might be at fault (for requesting such disruptive actions), KDE shares at least some of the blame: for acting on such requests, or for even allowing applications to make these requests. And it's not always thunderbird. A while back, I've observed similar behavior on a Lotus Notes client running under wine. In that instance it was even weirder: as Windows doesn't even have multiple virtual desktops, why would a Windows application issue such a request which would not even make sense in its natural environment? Or could it be that some component in between (wine, KDE, whatever...) was remapping an innocuous request to a "hijack desktop" request? I'll also report the issue to Mozilla, but somehow I've got the suspicion that the issue is more complex than that. In any case, setting the "Focus stealing prevention level" to "Normal" seems to prevent the behavior, even though it only takes effect if the focus policy is "Focus Follows Mouse". Even though it's still mysterious to me why mouse handling is related to desktop hijacking...
Also reported to Mozilla as https://bugzilla.mozilla.org/show_bug.cgi?id=482950 as per your request
I just tried it with fvwm, just to compare. On fvwm, mozilla doesn't yank my desktop around. Instead, the dialog box triggering it shows up on the current desktop (not perfect either, but still far better than being interrupted during your work by having pulled the desktop from under you)
The mozilla people (finally) reacted with technical details. Apparently what they do is: "gtk_window_present, which basically just sends a _NET_ACTIVE_WINDOW message to the WM" The intent is apparently to "just" steal focus (which is bad enough already...), but never to do any "manipulation of desktops whatsoever". So, KDE should at worst interpret this flag as a focus stealing request (without changing desktops), or better: not even honor it as a focus stealing request, but instead just flash the outline of the requesting window in the pager (so that the user is informed in a non-disruptive way that some window on another desktop is requesting his attention)
> So, KDE should at worst interpret this flag as a focus stealing request > (without changing desktops), or better: not even honor it as a focus stealing > request.... As you figured, that is actually the case with active focus stealing prevention, so to stress this, this is an issue with F(S)UM only. a) you can change void RootInfo::changeActiveWindow(.) in events.cpp (around line 150) <<< if (src == NET::FromTool) workspace->activateClient(c, true); // force else { // NET::FromApplication >>> if (src == NET::FromTool) workspace->activateClient(c, true); // force else if (options->focusPolicyIsReasonable()) { // NET::FromApplication =========== this can however have ugly side effects, so someone who really uses F(S)UM should test this on an everyday basis. b) any reason why you don't use FFM instead? I didn't name that option, but there are reasons to tag F(S)UM "unreasonable" - there's even been short discussion to remove them (completely or at least from the GUI config)
To prevent the obnoxious behavior, I've currently set "Focus stealing prevention level" to Medium/Normal (using a rule in "Window Rules", as the selector in Window behavior is greyed out) FFM actually makes the situation worse: I now need to set Focus stealing prevention to High instead, or else even normally inoffensive apps such as konsole start behaving funny. However, from past experience, I know that too high a Focus stealing prevention level has interesting side effect such as dialog boxes occasionally popping under instead of up. I'll now continue to use FFM + High and see what will happen... Why do you think F(S)UM is unreasonable? I've been using it (together with "Focus stealing prevention" = "Normal"/"Medium") for a couple of years without any obvious ill effects...
> FFM actually makes the situation worse: I now need to set Focus stealing > prevention to High instead, or else even normally inoffensive apps such as > konsole start behaving funny. Would you please specify "funny"? "Low" (the default) is entirely sufficient to me (except for some very nasty clients which get a special treatment) > I know that too high a Focus stealing prevention level has interesting side effect Non transient ones, yes. If the window is not permitted to get the focus, it will neither raise nor will it's VD be activated. > Why do you think F(S)UM is unreasonable? I didn't tag it, but the reason is likely that there's actually no focus management at all - whatever has the mouse, has the focus. Stealing prevention levels apparently cause other issues with F(S)UM, that's why they're forcefully disabled (see bug #48786 which describes the dialogs pop up behind, mostly a Gimp issue it seems) This will also be triggered by the mentioned patch, so if at all one should free the focus stealing policy and just default if to None for F(S)UM
>> konsole start behaving funny. > Would you please specify "funny"? It grabs focus when it starts up. >> I know that too high a Focus stealing prevention level has interesting side >> effect such as dialog boxes occasionally popping under instead of up. > > Non transient ones, yes. If the window is not permitted to get the focus, it This would be a new window (having just become visible), so why would it not be displayed on top of the stack, like any other new window? Or is this in order to avoid the window accidentally popping up under mouse, and getting focus that way? If that's the case, wouldn't it be more appropriate to have the window manager's placement algorithm avoid this situation by moving the new window enough so that it doesn't appear under mouse? > will neither raise nor will it's VD be activated. What is a VD? >> I'll now continue to use FFM + High and see what will happen... Back to FSUM + Normal : Indeed, with FFM + High, my "Window List" widget stopped working (was unable to switch desktop to chosen app). IMHO, what really should happen is that the window manager should be able to somehow whitelist its own widgets and accessories (pager, window list, ...) to allow them to switch desktop (these are widgets whose primary purpose is to manage desktops after all...), but forbid all other apps from messing with focus and desktop. The Mozilla guys mentioned a "messaging window" applet which sounds like some sort of icon box allowing to quickly jump to a number of messaging apps, including pidgin and thunderbird. What really should have happened is that they worked together with the window manager people to get special permission just for this app to switch desktops, but not redefine an existing window flag, which happens to be in widespread use by apps, to do it. >> Why do you think F(S)UM is unreasonable? > I didn't tag it, but the reason is likely that there's actually no focus > management at all - whatever has the mouse, has the focus. True... But unfortunately, the desktop hijacking still happens, and this too is governed by the "Focus stealing prevention level" in SystemSettings->WindowBehavior->WindowBehavior ... so even though with FSUM, it is hard for an app to steal focus (although some apps, such as emacs, try it anyways by wrapping the mouse to their window...), the setting still makes sense (or maybe, it could be renamed to "Desktop hijacking prevention level" if Policy is F(S)UM? ) > Stealing prevention levels apparently cause other issues with F(S)UM, that's > why they're forcefully disabled Well, what I did to get it anyways, was to define a rule in "Window Rules" that matches all windows (no window class nor role chosen in "Window" with "Focus stealing prevention" in "Workarounds" set to "Force" "Normal". This seems to stop all obnoxious desktop switching by Thunderbird and Firefox without any obvious negative side effect elsewhere > (see bug #48786 which describes the dialogs pop up behind, mostly a Gimp > issue it seems) I think I've seen similar issues, but mostly at the higher levels, not at "Normal". What I don't understand is, why does window stacking need to be tied to focus? Can't we have newly created (or newly mapped) windows appear on the top of the stack, but without interfering with desktop choice nor with focus (if necessary, move window a bit to avoid appearing just under mouse, and getting focus that way) > just default if to None for F(S)UM Right now the default is shown as "low" (i.e. one notch above "none"). Please keep focus stealing prevention at least as high as it is now.