[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=360878

kde@grau.net changed:

   What|Removed |Added

 CC||kde@grau.net
 Status|REPORTED|CONFIRMED
 Ever confirmed|0   |1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[Nick Cross via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

Nick Cross  changed:

   What|Removed |Added

 CC||k...@goots.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

Thomas Lübking  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=361940

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #16 from r...@alum.mit.edu ---
So there is still a problem: when I'm saving a document in LibreOffice, it
grabs focus away a couple of times when it's done even with focus stealing
prevention set to extreme and when I was typing into Firefox in a different
virtual desktop (which shouldn't matter -- my understanding is that with
FSP=extreme an application should *never* be able to grab focus, period).

FSP=high or extreme also renders the K menu completely useless; I had to run
systemsettings5 manually to set the FSP back to medium to be able to get the K
menu.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #15 from r...@alum.mit.edu ---
I see.

The comment "raising is split from activation, we are more generous on former,
so that the user does not easily miss windows that are denied activation" (from
reviewboard 124130) describes what I have in mind.  I want new top level
windows (as opposed to things like dialogs, menus, and such) to not get focus
unless I explicitly activate them by moving the mouse into them, but I do want
them to be visible.  But I don't think I want the timestamps to come into play.
 Even if I haven't typed into the current window in an hour, I don't want a
window that newly pops up to get focus.

There's the other problem of focus going to windows on a different virtual
desktop.  It's hard for me to see how that makes sense with any focus policy.

I can well believe there are a lot of corner cases here.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #14 from Thomas Lübking  ---
(In reply to rlk from comment #13)
> When I type "konsole", the *new* konsole window that pops up gets the focus 
> away from
> the existing one.

Yes, this is determined by the focus stealing prevention (as you figured)

> After 5 seconds, when the konsole popped up, the focus was
> switched to it despite medium focus stealing prevention.
Yes, because the medium FSP won't deny it under this circumstances (high will
if uncertain about the start time)
The new windows "start time" is newer than the last focus assignment or
"interaction" (usertime stamp)

The extreme FSP will keep the focus where it is, the high one if uncertain
about one of the timestamps and actuallly™ two konsole windows might end up in
the same group (depends on some attributes, didn't actually check) what might
allow them to distribute the focus "among" each other as it pleases them (but I
don't think so, there should be a correct PID split atm)

FSP isn't trivially doing "the right thing" and there's bug #110543 and
ultimately https://git.reviewboard.kde.org/r/124130/ (which would preserve the
focus on the if you're still typing in konsole at a reasonable speed)

FFM unlike FUM/FSUM *is* subject to focus distribution (that's the major
differentce between the first and second two policies); if you want to keep the
focus where it is, you'll have to pick extreme FSP.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #13 from r...@alum.mit.edu ---
No, because I haven't closed the first konsole window.  When I type "konsole",
the *new* konsole window that pops up gets the focus away from the existing
one.

The same thing happens with xterm or gnome-terminal: when I create a new
window, it gets the focus.

I tried another experiment: in an xterm, I ran

% sleep 5; konsole

and moved the mouse (and focus) to another window (tried with both firefox and
pidgin).  After 5 seconds, when the konsole popped up, the focus was switched
to it despite medium focus stealing prevention.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #12 from Thomas Lübking  ---
ffm is like Ctf, mInus the need to click. the focus is not bound to the mouse
position, but the fsp policy. the precedence is relevant to the focus decision
when a window is closed and the wm needs to select then next one.
this is *not* a bug.

the plasma popup situation is ridiculous, but unrelated. the popup is simply
buggy (due to caveats of qml)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #11 from r...@alum.mit.edu ---
Another, simple case:

0) Focus follows mouse, mouse precedence, focus stealing prevention medium,
both autoraise and click to raise turned off.

1) Start konsole, put it on the right hand side of the screen, leave mouse over
the konsole window.

2) In the konsole, run

konsole

Result: second konsole window gets focus.

Expected result: focus stays with the original konsole window

With focus stealing prevention high this doesn't happen, but then it's very
difficult to use the KDE menu from the panel (I have to explicitly defocus the
mouse by clicking over the root window in order to be able to use it).

So this would appear not to be related to focus under mouse.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #10 from r...@alum.mit.edu ---
Still happens in 5.6.0.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #8 from r...@alum.mit.edu ---
Ugh.  Virtual desktop switching is really bad news.  I just don't want the
focus to switch, period.  I'll be installing 5.6.0 shortly.  If it does
actually switch the desktop -- even with mouse follows/under focus -- I'll be
filing a bug against *that*.

Here is the xprop output (5.9.5):

_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE,
_NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT,
_NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN,
_NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 17, 0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 17, 0
_NET_WM_DESKTOP(CARDINAL) = 2
_KDE_NET_WM_ACTIVITIES(STRING) = "a69c2087-1863-4647-8743-f5bcff184776"
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT,
_NET_WM_STATE_MAXIMIZED_HORZ
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x98015e2
bitmap id # of mask for icon: 0x98015e3
window id # of group leader: 0x981
XdndAware(ATOM) = BITMAP
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 1385010480
_NET_WM_ICON(CARDINAL) =Icon (26 x 26):


░▒░  ░▒▒▒░
▒ ░░ ░
▒  ▒░ ░▒▒▒
▒   ▒░ ░▒▒
▒▒░ ░░
▒ ▒░  
▒  ▒░ 
▒   ▒░
▒    ▒
▒    ▒
▒  ▒   ▒  ▒   ▒  ▒
▒    ▒
▒  ▒   ▒  ▒   ▒  ▒
▒  ▓▒▒▓  ▒
▒  ▓   ▒  ▒   ▓  ▒
▒░ ▓▓▓▓ ░▒
▒░  ░▒
▒░  ░▒
▒░  ░▒
▒▒
░░




Icon (16 x 16):
 ░▒▒░  ░▒▒▒ 
 ▒  ░▒  ▒▒▒ 
 ▒   ░▒  ▒▒ 
 ▒░▒  ▒ 
 ▒ ░▒   
 ▒  ░▒  
 ▒  ▒▒▒  ░▒ 
 ▒  ▒  ▒  ▒   ▒ 
 ▒  ▒▒▒   ▒ 
 ▒  ▒  ▒  ▒   ▒ 
 ▒  ▒▒▒   ▒ 
 ▒  ▒  ▒  ▒   ▒ 
 ▒░ ▒▒▒  ░▒ 
 ▒░  ░▒ 
 ▒▒ 
 ▒▒ 


_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 159389149
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME(CARDINAL) = 1477809551
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x98015dc
WM_CLIENT_LEADER(WINDOW): window id # 0x981
_NET_WM_PID(CARDINAL) = 12263
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "rlk-mobile.rlk"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 0, 0
program specified minimum size: 0 by 0
window gravity: Static
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING,
_NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "libreoffice", "libreoffice-calc"
WM_ICON_NAME(STRING) = "rowing.ods - LibreOffice Calc"
_NET_WM_ICON_NAME(UTF8_STRING) = "rowing.ods - LibreOffice Calc"
WM_NAME(STRING) = "rowing.ods - LibreOffice Calc"
_NET_WM_NAME(UTF8_STRING) = "rowing.ods - LibreOffice Calc"

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #7 from Thomas Lübking  ---
Ok, please ensure  to test this on 5.6.0 - there's a good chance it's covered
by forementioned patch, but actually™ the virtual desktop should change
alongside the focus and it may be that LO underruns checks to "return" the
focus.

I though might have an idea what changed to cause this. Can you please take an
"xprop" (run it in konsole, click the window and attach the output) of the main
LO window that gets the focus (no matter when. ie. it's not required to have it
steal the focus etc.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #6 from r...@alum.mit.edu ---
Firefox, xterm, and pidgin, not LibreOffice.  All of my LibreOffice windows
(there were two documents in addition to the popup) are on the other virtual
desktop.

(To be precise, the FF, xterm, and pidgin are on VD#0, LO on VD#2, and 6
total.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #5 from Thomas Lübking  ---
What kind of window is active on the desktop you'd like to stay on. LibreOffice
one as well?

(Fyi, It's "::focusPolicyIsReasonable()" since KDE2 and we're not gonna draw a
git wall because users don't like how it's called :-P)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #4 from r...@alum.mit.edu ---
More information: I can reproduce this with focus follows mouse/mouse
precedence, with focus stealing prevention anything up to high.  It does not
happen with extreme focus stealing prevention.  It is not specific to focus
under mouse.

The particular operation I'm doing in LibreOffice is Insert->Names->Manage... .
 After I edit one of the names and click OK in the Manage Names dialog, the
dialog does not immediately pop down.  Instead, LibreOffice runs continuously
and hard for several minutes, after which the dialog goes away (that's not a
bug in LibreOffice per se; the spreadsheet is just ridiculously big and
complex).  That is the exact moment at which the window in the other virtual
desktop loses focus (as determined by watching the pager in the panel) and it
switches to the main LibreOffice window.  After that, LibreOffice continues to
run for another minute or so before accepting input.  By typing on the keyboard
and then switching back to the other virtual desktop, I can verify that the
keyboard focus has been given to LibreOffice.

(Just a gripe, I hate this term "unreasonable focus policies".  It's not
apparent what's unreasonable about wanting the focus to always remain under the
mouse.  I know alt-tab and such won't work, but I don't use them and never
have.  If I have a dozen or more windows up, alt-tab is useless to me because
it goes through them in no particular order.  I use keyboard accelerators to
raise/lower windows, and I can also select them from the panel.  I cut my teeth
on X9/X10 in the mid 1980's and really like that simple paradigm.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #3 from r...@alum.mit.edu ---
Also, the virtual desktop doesn't switch (which would be a problem in its own
right).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

--- Comment #2 from r...@alum.mit.edu ---
No dialog.  The LibreOffice window on the other virtual desktop simply gets the
focus and whatever window the mouse is under loses it.

This is LibreOffice 4.2.7, which is obsolete (I'm using it because I have this
horrendously complex spreadsheet that doesn't work properly on any newer
version due to bugs in LibreOffice, which are out of scope here).  So nothing
has changed there.

Again, there have been upgrades to both KDE Framework and QT5 that I installed
recently that may have coincided with this problem starting.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 360878] ::allowClientActivation should unconditionally return false for unreasonable focus policies

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360878

Thomas Lübking  changed:

   What|Removed |Added

Summary|focus stealing prevention   |::allowClientActivation
   |needed across virtual   |should unconditionally
   |desktops with focus |return false for
   |{strictly,} under mouse |unreasonable focus policies

--- Comment #1 from Thomas Lübking  ---
... or rather unconditionally on FSUM and if (active_client) on FUM.

There's a chance that your case is covered by
https://git.reviewboard.kde.org/r/127153/ (5.6.0, not sure whether it made it
into the beta)
It's unlikely (while possible) that this changed with a kwin release, maybe LO
switched to some KF5/Qt5 integration (does it show a dialog when the job is
done?)

-- 
You are receiving this mail because:
You are watching all bug changes.