Bug 215774 - a popup dialog should not steal window focus
Summary: a popup dialog should not steal window focus
Status: RESOLVED DOWNSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.3.2
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-23 04:07 UTC by brice rebsamen
Modified: 2020-03-08 15:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description brice rebsamen 2009-11-23 04:07:53 UTC
Version:            (using KDE 4.3.2)
OS:                Linux
Installed from:    Debian testing/unstable Packages

I guess it's not very easy to reproduce. Here is what happened just now: I was upgrading my packages in synaptic (I prefer synaptic, although it's a gnome app and I am using KDE). while synaptic was doing its job I was writing an email in firefox. At some point, configuration of one of the packages required my attention so a dialog poped up from synaptic, stealing the current focus. It happened to be just when I pressed the enter key to get a new line in my email, which resulted in pressing one of the buttons in the dialog. Consequently, I did not have the time to read the dialog, not even to see what package it was.

I seriously do not think this is a desired behavior, hence the bug report. IMHO the dialog should popup behind the active window and blink in the task bar. Actually this is what happens usually with other applications. It may be a problem with integration of Gnome apps in KDE...
Comment 1 lucas 2009-11-23 04:59:22 UTC
What is your "Focus stealing prevention level" set to in System Settings -> Window Behavior?
Comment 2 brice rebsamen 2009-11-23 05:09:00 UTC
It is set to low. I will increase it and see what happens. If the problem persists I will report again. Thanks
Comment 3 brice rebsamen 2009-11-23 05:29:06 UTC
I found a way to test: in synaptic, install package noip2: it asks for login information (popup dialog). To test again, remove package and config file (complete removal). Btw, the dialog window is called debconf.

Using a focus stealing prevention level of high, that debconf dialog does not steal the focus away.

I could not find any documentation about those levels. Is there any? Could I have the link? I guess some tooltips would help us make our choice.
Comment 4 lucas 2009-11-23 05:44:03 UTC
The combo box has a "what's this" tooltip that can be activated with the "what's this" button in the decoration (Which it seems that System Settings does not display so that's a problem...).

Quoted for easy reference:

"""
This option specifies how much KWin will try to prevent unwanted focus stealing caused by unexpected activation of new windows. (Note: This feature does not work with the Focus Under Mouse or Focus Strictly Under Mouse focus policies.)

None: Prevention is turned off and new windows always become activated.

Low: Prevention is enabled; when some window does not have support for the underlying mechanism and KWin cannot reliably decide whether to activate the window or not, it will be activated. This setting may have both worse and better results than the medium level, depending on the applications.

Medium: Prevention is enabled.

High: New windows get activated only if no window is currently active or if they belong to the currently active application. This setting is probably not really usable when not using mouse focus policy.

Extreme: All windows must be explicitly activated by the user.

Windows that are prevented from stealing focus are marked as demanding attention, which by default means their taskbar entry will be highlighted. This can be changed in the Notifications control module.
"""

By the sound of it is Synaptic that's broken as it doesn't use the normal focus handling calls and instead forces the window manager to focus the window instead.
Comment 5 brice rebsamen 2009-11-23 05:52:03 UTC
I will report this bug to the synaptic people and see what they think of it.

The normal focus handling calls you're talking about, are they standard calls that should be implemented by KDE and Gnome apps alike? Or is this a Gnome/KDE incompatibility that will be difficult to solve?
Comment 6 brice rebsamen 2009-11-23 05:57:03 UTC
this is actually a long standing bug in synaptic. See https://bugs.launchpad.net/synaptic/+bug/176002
Comment 7 lucas 2009-11-23 06:06:12 UTC
Well they are not actually "calls" as such; it's more of just how the windows are handled. An application should never request focus for any of it's windows unless they were created as a _direct_ response to a user action--e.g. the user clicking a button. A window appearing after a delay is not a direct user action and therefore the window should not be forcefully focused.

Details of how windows request focus can be found in the EWMH (Specifically _NET_WM_USER_TIME [1]) and KWin's activation.cpp file [2].

[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552314
[2] http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/activation.cpp?revision=1049334&view=markup