Bug 105809 - Background window incorrectly gains focus on desktop change
Summary: Background window incorrectly gains focus on desktop change
Status: RESOLVED DUPLICATE of bug 106818
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-17 13:18 UTC by Thomas McGuire
Modified: 2007-06-04 16:43 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas McGuire 2005-05-17 13:18:21 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    SuSE RPMs
OS:                Linux

When a window has focus and has "Skip Pager" & "Skip Taskbar" setting and another window is also on that desktop (without focus and in background), switching to another desktop and back results in the background window having focus despite being in the background.

To reproduce:

1. Open KControl on Desktop 1
2. Navigate to RMB Titlebar->Advanced->Special Window Settings...->Preferences
3, Check/Activate the "Skip taskbar" and the "Skip pager" setting ("Apply Initally")
4. Click "OK" button
5. Close and restart KControl. It should now not have a taskbar or pager entry
    It is not activated/does not have focus, but that seems to be another bug (or the same, I don't know)
6. Start Konsole on the same desktop
7. Click the titlebar of KControl so it gains focus, is activated and on the foreground
8. Switch to desktop 2 and afterwards back to desktop 1
9. Now the Konsole window has focus, but the KControl window should have focus because it is in the foreground

My focus policy is "Click to Focus" and "Click raise active window".
Comment 1 Lubos Lunak 2005-05-19 14:10:15 UTC
SVN commit 415713 by lunakl:

Since now it's possible to disable receiving focus for windows
in window-specific settings, no longer make skiptaskbar also
imply some kind of skiping focus.
BUG: 105809



 M  +1 -2      trunk/KDE/kdebase/kwin/client.cpp  


--- trunk/KDE/kdebase/kwin/client.cpp #415712:415713
@@ -1588,8 +1588,7 @@
 
 bool Client::wantsTabFocus() const
     {
-    return ( isNormalWindow() || isDialog())
-        && wantsInput() && !skip_taskbar;
+    return ( isNormalWindow() || isDialog()) && wantsInput();
     }
 
 
Comment 2 Oded Arbel 2005-06-09 11:04:52 UTC
Is this fixed on 3.4.1 ? as I see a similar (or same) behavior on my KDE 3.4.1 installed from Mandrake cooker RPMS.

It seems that "accept focus" in "window-specific settings" (is this 'wantsInput()' above ?) does not affect anything for "skip taskbar" windows. Which means that the above behavior happens for any window that is "skip taskbar" regardless of the setting for "accept focus".

Comment 3 Lubos Lunak 2005-06-09 11:24:28 UTC
SVN commit 423662 by lunakl:

Backport #105809.
CCBUG: 105809



 M  +1 -2      client.cpp  


--- branches/KDE/3.4/kdebase/kwin/client.cpp #423661:423662
@@ -1569,8 +1569,7 @@
 
 bool Client::wantsTabFocus() const
     {
-    return ( isNormalWindow() || isDialog() || isOverride())
-        && wantsInput() && !skip_taskbar;
+    return ( isNormalWindow() || isDialog() || isOverride()) && wantsInput();
     }
 
 
Comment 4 Oded Arbel 2005-06-09 11:49:30 UTC
Thx :-)
Comment 5 Lubos Lunak 2005-08-09 16:49:58 UTC
SVN commit 444278 by lunakl:

Revert r415713, at least for the time being, it causes more trouble
than it solves. I need to find a better way of fixing this.
CCBUG:105809



 M  +1 -1      client.cpp  


--- branches/KDE/3.5/kdebase/kwin/client.cpp #444277:444278
@@ -1611,7 +1611,7 @@
 
 bool Client::wantsTabFocus() const
     {
-    return ( isNormalWindow() || isDialog()) && wantsInput();
+    return ( isNormalWindow() || isDialog()) && wantsInput() && !skip_taskbar;
     }
 
 
Comment 6 Lubos Lunak 2005-08-09 16:52:03 UTC
I need to find a different way of solving this. KDE3.4.x will keep its old behaviour.
Comment 7 Oded Arbel 2005-08-10 10:23:02 UTC
Then why change the status to UNCONFIRMED ? I'm sure we all agree that this is a valid issue which should be solved ?

How about CONFIRMED instead ?
Comment 8 Lubos Lunak 2007-06-04 13:52:27 UTC

*** This bug has been marked as a duplicate of 106818 ***
Comment 9 Oded Arbel 2007-06-04 16:37:59 UTC
Why was this bug closed as duplicate ? First, this ticket already records some work committed towards solving the problem, unlike Bug 106818, so if any ticket should be closed as duplicate it should have been 106818.

Secondly, I don't believe these two bugs are duplicate of each other - Bug 106818 talks of being able to switch to "skip taskbar" windows with the keyboard - which not being able to is admittedly a problem, but it is classified as a wish. While this ticket talks about the current workspace not correctly remembering the focus of a "skip taskbar" window. I can see how the two issues may share the same implementation details, but unless we're sure this is the case - and IMHO this can be assured only by fixing both problems with the same patch - we shouldn't synthetically close one ticket as duplicate of another.
Comment 10 Lubos Lunak 2007-06-04 16:43:54 UTC
It is the same, just with different visible results, and the other bugreport has better description of the actual problem (skiptaskbar windows sometimes not getting focus).