Bug 242217 - Bug with shading always inactive windows
Summary: Bug with shading always inactive windows
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: unspecified
Platform: OpenSUSE Linux
: NOR normal (vote)
Target Milestone: 4.9
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-20 03:34 UTC by Grósz Dániel
Modified: 2012-04-17 19:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.9


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Grósz Dániel 2010-06-20 03:34:11 UTC
Version:           unspecified (using KDE 4.3.3) 
OS:                Linux



Reproducible: Always

Steps to Reproduce:
0. Use click-to-focus.
1. Start xvkbd or a similar application (e. g. dasher) whose window remains always inactive, even if you click in it.
2. Shade the window.
3. Move the mouse over the title to unshade it.
4. Move the mouse back to the window which was active before unshading.

Actual Results:  
The xvkbd window is shaded and becomes inactive and the other window remains inactive. It remains inactive even if you click in it, or click on its title bar, or click on its task bar entry.

Expected Results:  
The previously active window should become active.

You have to move the cursor to the previously active window immediately when you move it out of the xvkbd window. Obviously this requires the two windows not to be separatedby other windows or empty space.
Comment 1 Dirk Sarpe 2010-10-10 14:53:12 UTC
I tried to reproduce this bug and had to use slightly different steps:

0. Use click-to-focus.
1. Enable  hover in the advanced window behaviour
2. Start xvkbd
3. Shade the window.
4. Move the mouse over the title to unshade it. - Note that the decoration of the 'always inactive xvkbd' window actually becomes active now (e.g. alt+f3 works now in contrast to a xvkbd instance that was just started and not shaded).
5. Move the mouse back to the window which was active before unshading.

The results also differ a bit or maybe I missunderstood the original report: 
The xvkbd window is shaded and becomes inactive. The decoration of the other window remains inactive (no alt+f3 and displayed as inactive). The content of the window can be used as normal (e.g. changing tabs in a browser or typing text). The decoration remains inactive even if you click in it, or click on its title, but you can make it active by clicking another window and then the original window.

KDE 4.5.2 Kubuntu 10.10
Comment 2 Grósz Dániel 2010-10-10 16:00:30 UTC
It's the same for me. The steps are the same as what I did (just I forgot to tell the prerequisites 0 and 1 and that xvkbd becomes active when you unshade it).

Indeed, the other window seems to actually become active (I didn't try using the keyboard in it but it works), just the window decoration and the taskbar entry seems to be inactive.
Comment 3 Thomas Lübking 2012-04-16 17:16:05 UTC
have patch, make RR when being in vanilla master next time (creating from working branch is too much work with reviewboard - or i'm lazy ;-)
Comment 4 Thomas Lübking 2012-04-17 19:28:32 UTC
Git commit 1f571f40cdc7a1b58c2b58a15f579086f39b34dd by Thomas Lübking.
Committed on 16/04/2012 at 19:13.
Pushed by luebking into branch 'master'.

do not setActive clients which don't take focus on ShadeHover - by this resort re-shade restacking code
FIXED-IN: 4.9
REVIEW: 104622

M  +6    -7    kwin/client.cpp

http://commits.kde.org/kde-workspace/1f571f40cdc7a1b58c2b58a15f579086f39b34dd