Bug 304746 - Medium focus stealing prevention should also prevent focus stealing when the timestamp on the active window is uncertain
Summary: Medium focus stealing prevention should also prevent focus stealing when the ...
Status: RESOLVED DUPLICATE of bug 110543
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 4.9.0
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: 4.11
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-07 18:04 UTC by rlk
Modified: 2013-07-19 13:49 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Requested debug output (374 bytes, application/octet-stream)
2012-08-07 20:06 UTC, rlk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rlk 2012-08-07 18:04:02 UTC
Using focus follows mouse, medium focus stealing prevention, no auto raise, 0 ms delay focus, no click to raise.

If I start a KDE application from the command line in either xterm or konsole (thus far, I've tried kmines, konqueror, and konsole started from xterm), the new application gets the focus away from my xterm or konsole.  This does not happen if I start gimp 2.8 or GNU Emacs 23.3 (those applications do not steal the focus away).

With high focus stealing prevention, these applications (correctly) do not receive focus.

Reproducible: Always

Steps to Reproduce:
1. Set settings as above in details (FFM, medium focus stealing, no auto raise, 0 delay focus, no click to raise).
2. Start xterm or konsole.
3. From xterm or konsole window, type "kmines" or "konqueror".
Actual Results:  
New kmines or konqueror window receives focus.

Expected Results:  
New window should not receive focus; the existing xterm or konsole window should retain focus.

Because of 110543, it's difficult to use High focus stealing prevention, because new windows tend to get created where I'm least able to see them.  However, Medium focus stealing prevention is not doing what I believe from the documentation that it's supposed to.

The documentation for Medium focus stealing prevention is "Prevention is enabled."  It appears to me that the behavior is in direct contravention to the documentation.  I'm marking it Major as focus policy is a key part of window management and a major function of it is broken.
Comment 1 Thomas Lübking 2012-08-07 18:58:41 UTC
It's not a matter of toolkit but of timestamps.
Therefore also your description is wrong: (at least here) xterm does not update timestamps on interaction (for what reason ever) but konosle does.

As a result while typing in konsole no window will (easily, it's still possible to actually steal focus but eg. kwrite don't) steal the focus but when doing the same from xterm, every (including each gtk+ app i tried) will.

No idea about the documentation, but the definition in the code is clear:
    // 2 - normal  - focus stealing prevention is applied normally, when unsure, activation is not allowed

A possible improvement could be to also check whether the timestamp of the active window is undefined but the general behavior is as intended and for sure depends on your interaction with the currently active window.
Comment 2 rlk 2012-08-07 19:37:33 UTC
The behavior is the same for konsole and for xterm.  If I type

kmines

or

konqueror

in either, when kmines or konqueror pop up they steal focus away from the konsole or xterm.  If I run gimp or xterm from the terminal command line, they don't.

From a user perspective, it looks like focus has been stolen from the active window.
Comment 3 Thomas Lübking 2012-08-07 19:56:27 UTC
There must be sth. else then.
Please run kdebugdialog and activate "(1212) KWin", then restart kwin from konsole:

         kwin --replace > kwin.debug 2>&1 &

cause the focus stealing and attach kwin.debug

(you can then disable the debug out again)
Comment 4 rlk 2012-08-07 20:06:41 UTC
Created attachment 73038 [details]
Requested debug output
Comment 5 rlk 2012-08-07 20:08:21 UTC
This time, starting emacs or gimp from either xterm or konsole made no difference -- focus jumped to the new window both times.

Evidently I don't understand focus stealing.  I assumed focus stealing means that a window is prevented from grabbing focus; whether it's new or existing doesn't matter.  Is that assumption incorrect?
Comment 6 Thomas Lübking 2012-08-07 20:19:35 UTC
There's no debug output in the attachment - did you "apply" kdebugdialog before restarting kwin?

> This time, starting emacs or gimp from either xterm or konsole made no difference -- focus jumped to the new window both times.

As mentioned, it's about "activity" (eg. any keystroke) in the active window _only_

> I assumed focus stealing means that a window is prevented from grabbing focus; whether it's new or existing doesn't matter.

That does only hold for "extreme" fsp
The NETWM standard is "none" ie. when a window opens it will just get the focus, but that's aannoying so fsp was introduced quite early.

There's no real definition for its behavior and what it does is basically to check whether the window that wants the focus is related to the active on and whether there's currently interaction with the current window and based on that decide what to do.

The problem is that the outcome is too aggressive for some users and to weak for others and -worse- that many windows cannot reasonably state a relation (or are just broken) and are thus not passed the focus while they actually should.

Therefore the brainstorm proposal...
Comment 7 Thomas Lübking 2013-07-19 13:49:52 UTC
The RR on the dupe actually has this behavior (among other changes)

*** This bug has been marked as a duplicate of bug 110543 ***