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)
Created attachment 40309 [details] firefox - single application launched - which is ok
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.
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"
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.
i could reproduce the bug described for firefox
I could reproduce it with konqueror as well.
I could repoduce with Firefox, VLC, and okular.
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).
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.
Can't reproduce this bug (archlinux packages). >click on the task manager area I can't click on panel when app is fullscreen !?!?
@Bellegarde 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.
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
can one of the reporters try this with a window manager other than kwin? thanks.
(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?
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 ;)
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.
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.
I think the bug is fixed in KDE 4.4 :)
(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.
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).
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)
Ah yes, the bug is already there... :/ My FOCUS STEALING POLICY is set to none, and i've the problem anyway...
humm? 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?
IIRC kwin doesn't focus docks
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 ^^^^^^^^
:( 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!
The bug is still there with KDE 4.5.3... I hope it will get fixed before KDE 5 :-P
http://svn.reviewboard.kde.org/r/5790/
(In reply to comment #28) > http://svn.reviewboard.kde.org/r/5790/ Thanks. I applied the patch and it seems to fix the problem.
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
*** Bug 257576 has been marked as a duplicate of this bug. ***
This fix will be available in KDE 4.5.4 , schedule for november 24 ? Thank you so match for your work.
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.
So this commit will be available tomorrow (in KDE 4.6 beta)? http://techbase.kde.org/Schedules/KDE4/4.6_Release_Schedule "Wednesday, November 24, 2010: Beta 1 Release The beta becomes available for general consumption." Thank you !
"4.6 beta" - yes "tomorrow" - well, *iff* the schedule holds... ;-)
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.
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.
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
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
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
Java applications are still concerned by this bug :(
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.
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.
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 http://commits.kde.org/kde-workspace/3b0cb1a9e353683930e9755f158d425d3551ec0c