Bug 276156 - With "cursor follows mouse", input focus not always where mouse is located.
Summary: With "cursor follows mouse", input focus not always where mouse is located.
Status: RESOLVED DUPLICATE of bug 264368
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-20 23:20 UTC by George R. Goffe
Modified: 2011-06-21 00:08 UTC (History)
0 users

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

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description George R. Goffe 2011-06-20 23:20:48 UTC 
Version:           4.4 (using KDE 4.4.5) 
OS:                Linux

I am operating with "cursor follows mouse set". When I navigate via the keyboard settings for "alt-down" (toggle raise/lower and "alt-up" (raise). The "exposed" widget after "alt-down" does NOT have the focus.

Reproducible: Always

Steps to Reproduce:
set "alt+down" to toggle raise/lower widgets and "alt+up" to raise widgets


Actual Results:  
see details above.

Expected Results:  
see details above.

This behavior happens with FC 14, kde-4.6.3 (I don't know their latest right now but I AM using their latest).
Comment 1 Thomas Lübking 2011-06-21 00:08:36 UTC 
Nope, that focus models are called "(strictly) under mouse" - "follows mouse" only honors crossing events (real entering)

The reason is (likely) to prevent focus "stealing" (clients can raise any time, self induced or eg. when mapping on screen)

This is pretty much a dupe, see discussion there.

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