Bug 294019 - Window lower command (e.g. on middle button click on titlebar) ends up with focus loss
Summary: Window lower command (e.g. on middle button click on titlebar) ends up with f...
Status: RESOLVED DUPLICATE of bug 255052
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 4.7.2
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-13 20:43 UTC by Kirill
Modified: 2012-02-13 21:47 UTC (History)
0 users

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 Kirill 2012-02-13 20:43:15 UTC
Version:           4.7.2 (using KDE 4.7.2) 
OS:                Linux

I have smart focus, and set up left mouse button to focus and raise window, and middle button or wheel scroll to lower window. In older kwin everything was all right: I had way to raise/lower active window without moving mouse. Now to make my active window (e.g. text editor or konsole) under window with reference (web browser, pdf document, another console) and I click middle button on titlebar, my active window loses focus. Technically, there is no now simple way to put active window down, which is a huge problem.

Reproducible: Always

Steps to Reproduce:
RMB click on title bar, "Configure window behavior", "Actions", "Titlebar actions", Choose action on middle button to be "Lower", "OK". Then make any window active, click middle mouse button to titlebar.

Actual Results:  
Window gets lowered, but also loses focus, and some arbitrary window gains focus.

Expected Results:  
Window should go lower in z-order and keep focus.

If anyone considers, that the actual behavior is right, please take into account following:

1. it might be right with "Click to focus" policy, but not with "Focus follows mouse" or "Smart focus", when normally one should not have active window which does NOT contain mouse.

2. IF one argues this, separate action "Lower and blur" should be added instead of changing traditional behavior of "Lower" action.
Comment 1 Thomas Lübking 2012-02-13 21:47:24 UTC
Intended (what does not mean "correct") behaviour.
As a workaround, use "toggle raise & lower" which -inconsitently- does not show this behavior.

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