Created attachment 4519 A patch that seems to fix it. I have a set up with two monitors, as :0.0 and :0.1. When one of the monitors is showing a fullscreen window (e.g. a movie in vlc), and I click on a window on the other monitor to set focus to it, the fullscreen window disappears. Apparently, the window manager assumes that the window that is losing focus is on the same screen, and disables its fullscreen status. I've made a small patch, which is attached, that seems to correct the problem.
Created attachment 6363 Patch for 4.12.3 This is still an issue with 4.12.3. I've modified my patch to apply to that version and it still seems to cure the problem.
Just a me-too bug report. I can confirm the issue, whenever another window gets focus, the fullscreen window falls back in the stack, even when it's on a separate monitor. It makes multi-monitor use annoying enough that I switched away from XFCE for a while. Here a backtrace of the clientLower() call that causes the lowering of the fullscreen window: (gdb) where #0 clientLower (c=0x769410, wsibling=81789517) at stacking.c:450 #1 0x000000000043beb4 in clientAdjustFullscreenLayer (c=c@entry=0x769410, set=set@entry=0) at stacking.c:554 #2 0x0000000000420932 in clientUpdateFocus (screen_info=0x724c90, c=c@entry=0x0, flags=flags@entry=0) at focus.c:507 #3 0x000000000041dfc6 in handleFocusOut (ev=0x7fffffffd660, display_info=0x722e00) at events.c:1669 #4 handleEvent (ev=<optimized out>, display_info=0x722e00) at events.c:2235 #5 xfwm4_event_filter (xevent=0x7fffffffd660, data=0x722e00) at events.c:2297 #6 0x000000000041c4d2 in eventXfwmFilter (gdk_xevent=0x7fffffffd660, event=<optimized out>, data=<optimized out>) at event_filter.c:158 #7 0x00007ffff6401dc1 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #8 0x00007ffff64030c4 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #9 0x00007ffff6404ad6 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #10 0x00007ffff6404b7e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #11 0x00007ffff52e900d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x00007ffff52e92f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x00007ffff52e9612 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x00007ffff6790857 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #15 0x000000000040d3f4 in main (argc=1, argv=0x7fffffffdb58) at main.c:677 (gdb) quit I currently fixed that myself with a brute force: diff --git a/src/stacking.c b/src/stacking.c index 1d0a59a..1b41e78 100644 --- a/src/stacking.c +++ b/src/stacking.c @@ -547,7 +547,7 @@ clientAdjustFullscreenLayer (Client *c, gboolean set) } else if (c->win_layer == WIN_LAYER_FULLSCREEN) { - if (FLAG_TEST(c->flags, CLIENT_FLAG_FULLSCREEN)) + if (!FLAG_TEST(c->flags, CLIENT_FLAG_FULLSCREEN)) { TRACE ("Moving \"%s\" (0x%lx) to initial layer %d", c->name, c->window, c->fullscreen_old_layer); clientSetLayer (c, c->fullscreen_old_layer); But Bernd's patch might be better, as this one causes Alt-Tab to no longer raise windows.
(In reply to Ingo Ruhnke from comment #2) > Just a me-too bug report. I can confirm the issue, whenever another window > gets focus, the fullscreen window falls back in the stack, even when it's on > a separate monitor. > [...] Just to clarify, Bernd's patch is for multi-screen (aka Zaphod mode) - This is not for the general, usual multi-monitor setup. Sending fullscreen windows back to regular layer when they lose focus is on purpose and as designed. So the patch from comment #2 doesn't seem accurate to me. > It makes multi-monitor use annoying enough that I > switched away from XFCE for a while. No problem, there's plenty of desktops on Linux for you to choose from :)
> Just to clarify, Bernd's patch is for multi-screen (aka Zaphod mode) - This is not for the general, usual multi-monitor setup. Ah, ok, missed that bit. > Sending fullscreen windows back to regular layer when they lose focus is on > purpose and as designed. That behavior doesn't make any sense on a setup with multiple monitors. A typical situation is that you want to watch a video in fullscreen on one monitor and do something different on the other monitor. If you try that at the moment the fullscreen window will lose focus when you move the mouse to the other monitor and in turn it will no longer be on WIN_LAYER_FULLSCREEN. It fill fall behind whatever other windows are on the monitor. One can manually rearrange the video to be at the top of the window stack, but even then XFCE panel still gets in the way and stays on top, so there is no way to have a fullscreen window on one monitor while working on the other monitor. My patch just ignores attempts to remove the fullscreen window from WIN_LAYER_FULLSCREEN and that fixes the problem. But that's obviously not the correct way to do it, there would need to be some further checks that the window that got focus is actually on a different monitor, as when it is on the same monitor it should still be made visible (i.e. user selects a window that is behind the fullscreen window with Alt-Tab).
*** Bug 10990 has been marked as a duplicate of this bug. ***
*** Bug 12866 has been marked as a duplicate of this bug. ***
The problem is the Extended Window Manager Hints spec [1] recommends the stacking order as (copied here): 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 This does not work well with multiple monitors as losing focus of the fullscreen window to a window on the second monitor causes the fullscreen window to be drawn below the dock. This is not how other In the patch, focus no longer changes the fullscreen position. Instead it happens when a window is raised. If the raised window is on the same monitor as the fullscreen window, the fullscreen window is lowered. There are some decisions that should be made with this approach. I am not sure what the best behavior should be. Currently, the center of the window is used to decide which monitor it is on, this can cause part of the newly raised window to be under the fullscreen window if it is only partially on the second monitor. If a window is on top of the fullscreen window and then it is dragged to the other monitor, the fullscreen window does not go back to the top (above the dock). [1] https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER
Created attachment 8071 Patch for 9051, xfwm 4.12.5
Again, what you see as a bug is a design decision. With attachment 8071 , what if the user moves a window from another monitor onto the one where the fullscreen window resides? With that patch, the fullscreen window on the other monitor is kept on top, so the window being moved will not be visible, let alone accessible for the user to move it back...
That seems like a rather questionable design decision. Why would a user ever want to move a window over a fullscreen window? That seems to be a rather exotic and not exactly well supported use case. The moment the window loses focus it drops behind the fullscreen one anyway (with focus-follows-mouse) and options to control window stacking with a fullscreen window in the way are rather limited to begin with. Meanwhile having a video in fullscreen on a secondary monitor is an extremely common scenario in a multi-monitor setup and having the window drop from the front makes it impossible to view a video in fullscreen without having focus. Stay-on-top works as a workaround, but makes it extremely cumbersome to enter and leave fullscreen. If there is really any use for the current behaviour this needs to be an option at the very least. The current behaviour is rather useless from my point of view.
Also note that in the configuration I have, you can't drag a window between monitors. So that is not an issue. This really is a usability problem. "Working as designed" just means the design is wrong.
You are correct that moving windows behind a fullscreen window on another monitor will not be visible. So lets answer these three design decisions now and we can fix this problem so everyone is happy. 1) Should any part of a raised window overlapping with a fullscreen window cause the fullscreen window to lower? Or just the center which determines which monitor the task bar button is placed on? 2) Should moving a window off of a monitor with a fullscreen window cause the fullscreen window to go back above the dock? Should this be no more overlap or off of monitor as in 1)? 3) Should moving a window onto a monitor with a fullscreen window cause the fullscreen window to lower? Should this be any overlap or onto monitor as in question 1)?
Created attachment 8074 changes layer on window move and resize This patch lowers the layer when a window is moved or resized onto the monitor of a fullscreen window. It does not reraise the fullscreen window if the client is moved or resized off of the monitor. That gets tricky if one windows causes the lower, then another window is raised, then the first window is moved/resized off of the fullscreen monitor. This patch is consistent with openbox, except openbox seems to use a 'minimum overlap' rule for the decision instead 'center of window on the same monitor' rule.
Created attachment 8076 Fixed a bug in last patch. You are probably getting annoyed with me. But this fixes a bug with chromium moving tabs off of windows. That does not cause a normal move or resize event but instead a client configure event.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/84. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev