wrong window configuration after exiting full screen client

[imarko]

After upgrading to the latest exwm I noticed that when exit from a full screen mpv (the video player) the wrong emacs/exwm window configuration gets restored afterwards. Sometimes I lose one of the workspace frames too. I bisected this to the following change:

commit 0037cba87b1ceefc3a65fa3c458aa685689e7e27 (refs/bisect/bad)
Author: Chris Feng <chris.w.feng@gmail.com>
Date:   Sun May 13 23:57:36 2018 +0800

    Avoid hiding full screen X windows unexpectedly

    * exwm-layout.el (exwm-layout-set-fullscreen)
    (exwm-layout-unset-fullscreen): Set the Emacs window of a full screen
    X window dedicated to its buffer such that newly created X windows
    won't replace it.

diff --git a/exwm-layout.el b/exwm-layout.el
index 7642598..5b7fe99 100644
--- a/exwm-layout.el
+++ b/exwm-layout.el
@@ -165,6 +165,7 @@
                        :window exwm--id
                        :data (vector xcb:Atom:_NET_WM_STATE_FULLSCREEN)))
     (xcb:flush exwm--connection)
+    (set-window-dedicated-p (get-buffer-window) t)
     (cl-pushnew xcb:Atom:_NET_WM_STATE_FULLSCREEN exwm--ewmh-state)
     (exwm-input--release-keyboard exwm--id)))

@@ -193,6 +194,7 @@
     (xcb:+request exwm--connection
         (make-instance 'xcb:ewmh:set-_NET_WM_STATE :window exwm--id :data []))
     (xcb:flush exwm--connection)
+    (set-window-dedicated-p (get-buffer-window) nil)
     (when exwm--keyboard-grabbed
       (exwm-input--grab-keyboard exwm--id))))

When I revert this from current master things are good again.

I have only tried this with my personal config and with multiple randr workspaces. Please let me know if it doesn't reproduce trivially and I can try to narrow it down further.

[ch11ng]

Please verify if this has been fixed with 13a14579cc1bb772735f895dd5b4b90c6812f3ee.

[imarko]

Looks fixed with 13a1457, thanks!

[imarko]

Ran into another edge case with this but not sure if it should be considered an exwm issue or my personal configuration but I thought I'd mention it.

I have an exwm key binding for doing (switch-to-buffer nil) that I often use to toggle between the current and the next buffer. With set-window-dedicated-p in effect on a full screen window this results in popping into a new window instead of the current one and the X client remains full screen but no longer focused and I have to blindly navigate to the correct window to get back control.

Without the dedicated window the toggling between the full screen X client and the next buffer works as expected.

[ch11ng]

What should be the expected behavior? Keeping the focus staying on the full screen X window, or displaying the new buffer?

The original behavior was full screen X windows stay in char-mode so that they won't get disturbed by ordinary Emacs commands.

[medranocalvo]

@imarko, does this still happen with latest updates? Could you answer @ch11ng's questions?

[imarko]

Sorry, I missed this earlier. Yeah, the behavior I described in https://github.com/ch11ng/exwm/issues/458#issuecomment-408967615 is still there. I am working around it by unsetting fullscreen (and hence dedicated-p) before doing the (switch-to-buffer nil).

As far as the expected behavior, when I trigger the keybinding for (switch-to-buffer nil) I would expect the new buffer to appear since it's an explicit user intent. But there are exceptions, for some multiplayer games I don't want to get dropped out of fullscreen mode when I accidentally hitting the wrong key so I have some checks against that.

Another case is when some timer event (for example a calendar appointment) causes a new window to be displayed. I personally wouldn't want this to affect the fullscreen window but this is a personal preference.

So I guess the answer is "it depends"

But it would be great to avoid the case where a new buffer gets focused and placed in a window obscured by the fullscreen window since this is very confusing to the user and you have to recover from it blindly as your commands are going to a buffer not currently visible.

[medranocalvo]

Thank you for following up.

I managed to reproduce the issue. Indeed, current behaviour could be improved. I would say that the X client should exit fullscreen if its exwm-mode buffer either:

• becomes longer displayed in the workspace, or
• loses focus.

This possibly conflicts with the fix for #421, which dedicates `exwm-mode' buffers of fullscreen X clients to their original window. @ch11ng, do you recall why did https://github.com/ch11ng/exwm/commit/0037cba87b1ceefc3a65fa3c458aa685689e7e27 fix #421?

[imarko]

Perhaps setting dedicated-window-p could be put behind a defcustom?

[ch11ng]

do you recall why did 0037cba fix #421?

Consider a sole Emacs window of a workspace displaying an exwm-mode buffer. After making the X window full screen and then create a new X window in some way, the underlying buffer would get replaced by the exwm-mode buffer of the newly created X window. As a result the full screen X window would become invisible. That fix makes the buffer of a full screen X window dedicated so in this case a new Emacs window would get created and the full screen X window would remain intact.

I agree with @medranocalvo that a full screen X window should exit full screen mode when input focus shifts to another X window on the same workspace. It won't resolve @imarko's problem though: the dedicated state has to been removed first before making a buffer switch.

[Artefact2]

I can still reproduce this issue, here is how:

• Start firefox on workspace 3
• Start playback of a full-screen video on workspace 2 with mpv
• Switch to workspace 1, let the playback end
• Firefox is now on workspace 2

Any ideas on how to solve (except "don't do that, duh" ;-)) ?

[imarko]

@Artefact2 To make sure it's actually related to this, does reverting the commit mentioned in the original report make a difference? An easy way to test is to M-x find-library exwm-layout.el, comment out the two set-window-dedicated-p lines and C-M-x for each to eval the defun-s containing them.

For my part I am still running with this commit reverted because of the case mentioned in https://github.com/ch11ng/exwm/issues/458#issuecomment-408967615

[Artefact2]

@imarko That worked, thanks. I'll do the same as you from now on.

[kinleyd]

Thanks. This has been bugging me for a bit now.