Bug 224600 - task manager and panel stays above fullscreen application; affects all apps which supports full screen with shortcuts, e.g., smplayer, dragonplayer, firefox, bangarang, okular
Summary: task manager and panel stays above fullscreen application; affects all apps w...
Alias: None
Product: kwin
Classification: Plasma
Component: compatibility (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
: 257576 (view as bug list)
Depends on:
Reported: 2010-01-28 10:58 UTC by Mohd Asif Ali Rizwaan
Modified: 2013-03-20 21:24 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:

firefox - single application launched - which is ok (206.95 KB, image/png)
2010-01-28 11:01 UTC, Mohd Asif Ali Rizwaan
firefox - fullscreen after clicking on empty space on task manager (159.22 KB, image/png)
2010-01-28 11:03 UTC, Mohd Asif Ali Rizwaan
smplayer - fullscreen after clicking on the task manager space. (106.47 KB, image/jpeg)
2010-01-28 11:09 UTC, Mohd Asif Ali Rizwaan
this bug also affects videolan client (vlc player) (86.60 KB, image/jpeg)
2010-01-28 11:18 UTC, Mohd Asif Ali Rizwaan

Note You need to log in before you can comment on or make changes to this bug.
Description Mohd Asif Ali Rizwaan 2010-01-28 10:58:29 UTC
Version:           unknown (using 4.3.95 (KDE 4.3.95 (KDE 4.4 RC2)), Kubuntu packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.31-18-generic

Panel (taskmanager, systemtray, clock, applets) stays above (overlaps) full screen application. This overlapping panel behavior affects all applications which supports fullscreen ('f' key, ctrl+shift+f, f11 key)

How to reproduce:

1. open firefox/konqueror/smplayer/dragon player
2. we can see task button on the task manager (inside panel) (see attachments for better clarity)
3. press f11 (or the fullscreen shortcut key)
4. the application becomes full screen and panel hides behind the application.

the buggy part:
5. click on the task manager area (where there are no buttons or on system tray icons like keyboard layout, or clock (or double click on kmix/klipper/or kmenu button to show and hide the menu)
6. we can observe that the single taskbutton of firefox/konqueror/smplayer/dragonplayer application, stays "Active" and is always ready to accept keyboard shortcuts, this is what causing the bug.

7. press f11 (for firefox/konqueror) or f key(for smplayer, dragonplayer)
8. we can observe that the panel stays above the fullscreened application.

Expected behavior:

1. the taskbutton should lose the "focus" when we click on other items (system tray, etc.)
2. the taskbutton should regain full focus, so that fullscreen should work as expected (without panel overlay)
Comment 1 Mohd Asif Ali Rizwaan 2010-01-28 11:01:45 UTC
Created attachment 40309 [details]
firefox - single application launched - which is ok
Comment 2 Mohd Asif Ali Rizwaan 2010-01-28 11:03:49 UTC
Created attachment 40310 [details]
firefox - fullscreen after clicking on empty space on task manager

please observe the whiteness of the panel which is caused by the firefox fullscreen window.
Comment 3 Mohd Asif Ali Rizwaan 2010-01-28 11:09:55 UTC
Created attachment 40311 [details]
smplayer - fullscreen after clicking on the task manager space.

video behind the panel can be seen.

And panel will stay above no matter how many times we press fullscreen (normal window) shortcuts.

We need to click on the task button, then only we'll have "true fullscreen"
Comment 4 Mohd Asif Ali Rizwaan 2010-01-28 11:18:45 UTC
Created attachment 40312 [details]
this bug also affects videolan client (vlc player)

I guess, this bug also affects the "Fullscreen" of vlc, as vlc has 2 windows the interface and the video, when fullscreen is called with f shortcutkey, the xvideo window gains focus and as the focus changes, the panel-focus-fullscreen bugs makes it impossible for vlc to overlap panel.
Comment 5 Beat Wolf 2010-02-01 22:38:28 UTC
i could reproduce the bug described for firefox
Comment 6 Piotr 2010-02-02 00:51:42 UTC
I could reproduce it with konqueror as well.
Comment 7 Inso 2010-02-02 07:37:44 UTC
I could repoduce with Firefox, VLC, and okular.
Comment 8 Stefan Majewsky 2010-02-02 13:21:05 UTC
Can reproduce with Konq and Firefox and Okular, on 4.3.98 openSUSE RPMs.

The bug is also reproducible if one uses KWin's ability to fullscreen any window (tested with Palapeli here).
Comment 9 Nikos Chantziaras 2010-02-03 10:06:22 UTC
I was about to file a bug about the same thing. Reproducible with any app I tried, regardless of whether it's a KDE, Qt, Gtk, whatever app.
Comment 10 Cédric Bellegarde 2010-02-03 12:43:54 UTC
Can't reproduce this bug (archlinux packages).

>click on the task manager area

I can't click on panel when app is fullscreen !?!?
Comment 11 Piotr 2010-02-03 14:26:06 UTC

The point is that you click panel when any application ISN'T in fullscreen, the point is that keyboard shortcut still works with the application you are using but it doesn't cover the panel anymore.
Comment 12 Nikos Chantziaras 2010-02-03 23:47:55 UTC
The way I actually encountered this was another one (happens far more often):

Have three applications open, say two Dolphin windows and SMPlayer. All of them have to be visible (that is, not minimized).  Now, close or minimize the two Dolphin windows.  You will see that SMPlayer, being the only visible application/window left on the desktop, will automatically get focus without needing to click on it first.  Since it has focus, it gets key presses.  Now press "f" to make it fullscreen.  This will result in the bug we're talking about here. Furthermore, not only is the panel visible, but KDE doesn't really treat it as fullscreen and the rendering is not un-redirected.

The above happens far too often when I watch a video (SMPlayer) or TV (tvtime).  When I close or minimize all other windows and SMPlayer or tvtime get focus automatically (being the last remaining visible window), when I switch to fullscreen, the bug manifests.  To avoid this, I have always to first click somewhere else on the desktop (so that the windows loses focus again), then click the window again (so it gets focus manually) and only the go to fullscreen. As you can guess, this is pretty annoying :P
Comment 13 Aaron J. Seigo 2010-02-04 00:45:41 UTC
can one of the reporters try this with a window manager other than kwin? thanks.
Comment 14 Nikos Chantziaras 2010-02-04 02:10:46 UTC
(In reply to comment #13)
> can one of the reporters try this with a window manager other than kwin?
> thanks.

I've installed LWM and then Blackbox, but "System Settings->Default Applications->Window Manager->Use a different window manager" still stays grayed out and I can't select neither of them.  Is there something wrong or do I need some specific WMs that KDE can cope with?
Comment 15 Aaron J. Seigo 2010-02-04 03:40:07 UTC
you can just open up a konsole window and do: blackbox --replace

or, if blackbox doesn't understand --replace (i seem to remember it doing so, though?), then do: `killall -9 kwin; blackbox` (be sure to do it all on one line like that otherwise getting keyboard focus back into the konsole window after kwin is gone can be highly annoying ;)
Comment 16 Nikos Chantziaras 2010-02-04 04:19:55 UTC
OK, tried with Blackbox. It's impossible to try reproducing the behavior since Blackbox does not automatically give focus to another window if the one that currently has it gets closed or minimized.

I tried other window managers (afterstep, wm2, lwm) but none of them worked correctly, resulting in an unusable desktop.
Comment 17 Mohd Asif Ali Rizwaan 2010-02-04 19:31:10 UTC
the "sawfish window manager" has appropriate behavior (the taskbutton do not stay active when we click on other plasma objects)

Aaron, it seems kwin is responsible for this bug.
Comment 18 Inso 2010-03-08 12:22:44 UTC
I think the bug is fixed in KDE 4.4 :)
Comment 19 Nikos Chantziaras 2010-03-08 20:23:57 UTC
(In reply to comment #18)
> I think the bug is fixed in KDE 4.4 :)

No, it is not.  I'm on 4.4.1.
Comment 20 Aaron J. Seigo 2010-03-09 05:41:25 UTC
it seems the problem here is that when the panel (a Dock window) has been clicked on, fullscreen windows go behind them. this is replicatable with krunner in current trunk as well (it is also now marked as a Dock window). clicking on it (even if the line edit does not have focus) and then hitting F11 when Firefox is up will cause the Firefox window to go fullscreen behind all the Dock windows (plasma-desktop as well as krunner).
Comment 21 Thomas Lübking 2010-03-09 16:54:40 UTC
the problem is that the first click on a dock type window does raise it, but not take the focus from the previous window (the second click will do so)

the reason is the FOCUS STEALING POLICY "medium" which triggers this (setting it to none "fixes" it)
Comment 22 Inso 2010-03-09 17:31:11 UTC
Ah yes, the bug is already there... :/

My FOCUS STEALING POLICY is set to none, and i've the problem anyway...
Comment 23 Thomas Lübking 2010-03-09 17:46:19 UTC
despite no focus stealing prevention you can click a dock and the focus remains on the former active window??

what kind of focus policy do you use, or do you trigger the fullscreen mode via a global shortcut?
Comment 24 Martin Flöser 2010-03-09 17:51:38 UTC
IIRC kwin doesn't focus docks
Comment 25 Thomas Lübking 2010-03-09 21:10:38 UTC
yupp, sorry - seems to be a conky thing :-\
just setting _NET_WM_WINDOW_TYPE_DOCK on a random window will just raise, but never change any focus...

we then have a bug, as the netwm stacking says:

windows of type _NET_WM_TYPE_DESKTOP
windows having state _NET_WM_STATE_BELOW
windows not belonging in any other layer
windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE

focused windows having state _NET_WM_STATE_FULLSCREEN
Comment 26 Julien Gouesse 2010-03-13 16:57:25 UTC
:( It affects Java games too!! What a shame! It sucks! We already had some problems with Metacity some years ago, now it comes from KDE. Please fix this bug ASAP!
Comment 27 Nikos Chantziaras 2010-11-07 16:37:22 UTC
The bug is still there with KDE 4.5.3... I hope it will get fixed before KDE 5 :-P
Comment 28 Thomas Lübking 2010-11-08 00:16:56 UTC
Comment 29 Nikos Chantziaras 2010-11-08 16:39:51 UTC
(In reply to comment #28)
> http://svn.reviewboard.kde.org/r/5790/

Thanks. I applied the patch and it seems to fix the problem.
Comment 30 Thomas Lübking 2010-11-10 04:08:06 UTC
SVN commit 1194908 by luebking:

workaround bug 224600 / active but unrisen windows don't go fullscreen

NOTICE that the correct solution would be to move any active FS client on top of the stack in layers.cpp but this might raise other issues.
this patch preserves the present behaviour but raises windows before setting the fullscreen. the only "issue" with this is that for setups that do not raise windows when activating them, setting an active but not risen client FS will cause a restack as sideeffect

BUG: 224600

 M  +2 -0      geometry.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1194908
Comment 31 Beat Wolf 2010-11-22 11:26:42 UTC
*** Bug 257576 has been marked as a duplicate of this bug. ***
Comment 32 Maxi C 2010-11-23 17:42:45 UTC
This fix will be available in KDE 4.5.4 , schedule for november 24 ?

Thank you so match for your work.
Comment 33 Thomas Lübking 2010-11-23 23:18:30 UTC
since this is technically a behavioural change, it's been decided to NOT backport the patch. it will apply in 4.6 beta first. sorry.
Comment 34 Maxi C 2010-11-23 23:42:15 UTC
So this commit will be available tomorrow  (in KDE 4.6 beta)?


"Wednesday, November 24, 2010: Beta 1 Release 

The beta becomes available for general consumption."

Thank you !
Comment 35 Thomas Lübking 2010-11-23 23:57:42 UTC
"4.6 beta" - yes
"tomorrow" - well, *iff* the schedule holds... ;-)
Comment 36 Maxi C 2010-12-03 20:44:55 UTC
I recently updated to 4.6 beta 1 (Kubuntu Maverick 10.10)

The problem is NOT resolving , in SMPlayer running in fullscreen you still cant hover over the progress bar , because kde taskbar try to raise.

Please address this.

Thank you.
Comment 37 Maxi C 2010-12-03 20:45:30 UTC
I recently updated to 4.6 beta 1 (Kubuntu Maverick 10.10)

The problem is NOT resolved , in SMPlayer running in fullscreen you still cant hover over the progress bar , because kde taskbar try to raise.

Please address this.

Thank you.
Comment 38 Thomas Lübking 2010-12-03 21:05:10 UTC
re-read OP.
i doubt that you're talking about the same bug.

just tested your case and it works as expected even in 4.5 (and esp. with autohiding panels which could not cause this issue) - unless you use compositing/unredirection.

So you probably suffer from the unredirection issue which is not covered by this bug/fix and prevents sane usage of the smplayer bottom bar regardless of any autohiding panels, sorry: this problem is a bit more complex remains unfixed, but you can turn off unredirection on performance cost:

kwriteconfig --file kwinrc --group Compositing --key UnredirectFullscreen --type bool false && qdbus org.kde.kwin /KWin reconfigure

or just suspend compositing by shift+alt+f12
Comment 39 Maxi C 2010-12-03 22:17:30 UTC
Sry then , but i came here because my opened bug form (https://bugs.kde.org/show_bug.cgi?id=257576) was marked as duplicated of this bug.

I'll try that then..
Thank you
Comment 40 Thomas Lübking 2010-12-03 22:35:56 UTC
those might actually be unrelated issues - it's possible that wine/SC2 doesn't acutally run fullscreen (just maximized, undecorated & raised, you can use "xprop"* to investigate this. the panel is then allowed to show up) while i'm pretty sure you're hitting the unredirection bug with smplayer (when the bottom panel shows up, smplayer gets re-redirected. this hides the panel, smplayer gets unredirected et voilá: you've got a race)

in general autohiding panels didn't raise above active fullscreen windows anyway.
this bug was about kwin failing to mark an unraised but active window fullscreen (thus the workaround to pre-raise it)

*eg. "sleep 60; xprop > ~/wine-prp.txt" will wait 60 seconds and then change the cursor. you can click the window and the properties are dumped into the file ~/wine-prop.txt
Comment 41 Julien Gouesse 2011-06-21 10:47:35 UTC
Java applications are still concerned by this bug :(
Comment 42 szymon 2013-03-16 10:09:05 UTC
I think that this bugs is still unresolved. Try to open konsole (which as native kde software should work correctly) in fullscreen mode. Then change desktop to another desktop (with some shortcut) and on the second desktop change currently opened window to another one. When you will be back in the konsole desktop then you will see that task manager is on top and should not be because konsole is still the current active program on that desktop. 
It's really irritating. I work very often on two desktops and have one with konsole and another one with web browser so it's annoying when you have to click F11 twice to re-size konsole.
Comment 43 Thomas Lübking 2013-03-16 12:29:44 UTC
That's bug #296076
This bug has turned into a collection of "all reasons why this happens" while bug #296076 specifies the only remaining one.
Comment 44 Thomas Lübking 2013-03-20 21:24:37 UTC
Git commit 3b0cb1a9e353683930e9755f158d425d3551ec0c by Thomas Lübking.
Committed on 18/03/2013 at 17:26.
Pushed by luebking into branch 'master'.

Depend fs layer upon active state, not stackorder

according to NETWM spec implementation notes suggests
"focused windows having state _NET_WM_STATE_FULLSCREEN" to be on the highest layer.
We'll also take the screen into account
The user set stacking (being raised) is not considered by the spec note
This behavior is also suggested by an old comment in activation.cpp, void Workspace::setActiveClient()
Related: bug 296076
REVIEW: 109572
FIXED-IN: 4.11

M  +5    -16   kwin/layers.cpp
M  +9    -2    kwin/workspace.cpp