EXWM occasionally overlays incorrect X windows

[tazjin]

EXWM version: 0.18 (latest ELPA release, see here)

EXWM config

---

Sometimes when switching buffers in an EXWM session, EXWM overlays a seemingly random X window over the buffer that I actually wanted.

For example, I may have a split-screen layout with two windows each showing a text buffer and switch to a different buffer in one of the windows - suddenly EXWM overlays an open Spotify window over that buffer (but *Spotify* is not the selected buffer) which does not go away until I click the window and actually make it active (at which point workspaces are often switched).

I've read through previous issues and commits but couldn't find anything related except maybe #378 - but those commits are included in the version of EXWM that I use.

This did not occur in EXWM versions prior to 0.16. If I had a reliable way to reproduce it I'd try git bisecting it, but I haven't found one yet :/

[ch11ng]

This may have something to do with exwm-workspace-show-all-buffers and exwm-layout-show-all-buffers which you have turned on. I've just proofread the relevant code but have no clue what can cause this. Perhaps more details are required:

1. Is this a multi-monitor setting?
2. Do you have the exwm-randr module enabled?
3. Does it happen only on a newly created workspace?
4. How do you switch to a different buffer?
5. Is Spotify the only app that suffers from this?
6. Before Spotify is wrongly displayed, is it active on another workspace?

[tazjin]

1. On one machine, yes. The other one only has a single monitor. Both use the same configuration.
2. Yes.
3. No, I create 10 workspaces at launch and don't modify them.
4. This happens both with exwm-workspace-switch-create and default C-x b.
5. No, it seemed like it happened more often with alacritty (a terminal emulator), but that is probably biased perception because it is my most used X app.
6. Yes, and it is incorrectly overlaid at the same size that it was on the old workspace.

---

I read through the docs of those two variables you mentioned again and exwm-layout-show-all-buffers seems like the one I want (and use all the time) to switch to buffers on other workspaces, but I'm not sure I understand the documentation of exwm-workspace-show-all-buffers - what does "show" mean here?

Going to dig through the source a bit and also attempt disabling that.

[ch11ng]

exwm-workspace-show-all-buffers is required or you won't be able to see buffers on other workspaces. Quite a few users set these two variables AFAIK but it seems they are not affected. I wonder if there are other settings to blame.

[tazjin]

I've not found a reliable way to reproduce this, it just happens totally randomly as far as I can tell. For now I'm going to revert back to EXWM 0.15

[ch11ng]

Sorry to hear about that. #422 may be related which also have these two switches on. You may want to turn on debugging to see why an X window is displayed when you get the time.

[tazjin]

It does actually seem like certain X applications are more likely to encounter this issue, I haven't seen it with Firefox for example but it's almost guaranteed to eventually happen if a Spotify window exists.

You may want to turn on debugging

Do you mean some EXWM-specific debugging feature or generic elisp tracing/debugging?

[ch11ng]

I mean exwm-debug-on.

[AndreaOrru]

I'm also having the same issue - it happens mostly with Chromium and Slack and it's seemingly random.

Here is my EXWM configuration, may be useful to triage: https://gist.github.com/AndreaOrru/1ddcd82c95beb8250bf17871d276f828

[tazjin]

@AndreaOrru Finally I'm not alone with this anymore ;D

Lets see if there's any suspicious options that we both set ...

Do you run a compositor?

[AndreaOrru]

@tazjin No, running this on bare X server with fbdev driver. Forgot to say I run Spacemacs (develop branch) and Emacs 27 (very latest git revision), if that makes any difference.

I can try and reduce the configuration to the bare essentials, but I feel it's pretty close to the defaults already (apart from some shortcuts). You said EXWM 0.16 is the first revision to break?

[tazjin]

@AndreaOrru Yes, it works fine for me on versions prior to 0.15 (but they have other issues, so it's a tradeoff question right now).

If there was some set of actions to reliably reproduce it we could git bisect exwm and find the cause - but I haven't been able to identify any patterns (other than "happens when you least expect it").

You also have exwm-workspace-show-all-buffers and exwm-layout-show-all-buffers set, which may somehow be related.

[AndreaOrru]

Well, those options give you the ability to take a window that's sitting in a different workspace and bring it to the current one - I find that this issue mostly comes up when you do that, or when you switch workspaces.

[tazjin]

I've now set up exwm-debug-on on my machine to see if I can make out any related log entries when this occurs, but it hasn't happened all day :thinking:

[tazjin]

@AndreaOrru Did you ever find out anything more about this? I had exwm-debug-on running for a bit on one machine but found no interesting entries.

[AndreaOrru]

I moved to xmonad :(

[tazjin]

Too bad, it's strange that nobody else seems to have encountered this, though this comment in #458 describes something that sounds vaguely related (except with the fullscreen bit, but the symptoms sound similar).

I've unsuccessfully tried to git bisect this problem, however there's no reliable way to figure out whether a revision is not affected because sometimes it just doesn't occur for a while ... :thinking:

[dakra]

@tazjin I have the same problem, but like you it's really hard to figure out what's exactly wrong as I can't reproduce it step-by-step and it just happens "sometimes". That sometimes is pretty regularly but my only X applications are Firefox and Pidgin so it's not something that was so annoying that I would invest multiple hours to debug it.

[ch11ng]

aebcb0344f18b1aa284a432811175fde2d2feae5 may solve the problem to some extent. Please give a try and report back.

[tazjin]

@ch11ng Thanks, I've updated to that version! :tada: The bug is notoriously hard to trigger on purpose, so it'll be a while before I can say anything about whether it helped :)

[tazjin]

@ch11ng The same issue has occured twice since I upgraded to master, though it does appear to occur less frequently. Maybe there are multiple things with similar symptoms :thinking:

[ch11ng]

I've found a way to trace this issue in more details: put (require 'backtrace) into your .emacs and (write-region (backtrace-to-string (backtrace-get-frames 'backtrace)) nil "/path/to/logfile" t) at the beginning of exwm-layout--show ("/path/to/logfile" is the log file to record the backtrace; be sure there is sufficient disk space). When the issue is reproduced, report back the last few backtraces together with the output of xwininfo -tree -root -int and the application name.

[medranocalvo]

I believe #469 might fix this issue. Please test it.

[tazjin]

@ch11ng I have been busy with a lot of other stuff this week, didn't get around to apply your debugging suggestion yet, sorry!

@medranocalvo That sounds interesting, same note applies - I'll try to test both things this weekend. Thanks :)

[medranocalvo]

That's fine. Have a good day.

[tazjin]

@medranocalvo I just added your PR to my local setup (that was the most low-hanging fruit out of the two options) and now the behaviour of the issue seems to have changed slightly. Any X windows opened immediately after starting EXWM get stuck in the front forever, but can still be resized / split etc if they are active.

After using xrandr to configure the second screen correctly, the issue seems to (temporarily?) disappear after clicking into every window once. I'll leave this running now and see what happens, but specifically this last bit sounds a bit as if randr had something to do with it.

[tazjin]

Update, after about 8 hours of using @medranocalvo's changes: It hasn't occured during normal use once (which doesn't prove that it's fixed due to the rarity of it, but still). It now reproducibly happens whenever I change the screen setup (on a laptop, so multiple times a day). This means I can apply @ch11ng's debug suggestion and hopefully trace down that issue.

[ch11ng]

@tazjin, with @medranocalvo's new debug trick you can now simply set exwm-debug-on and watch changes in the *EXWM-DEBUG* buffer.

[medranocalvo]

@tazjin please check whether #477 resolves this issue.

[tazjin]

@ch11ng @medranocalvo I've updated to the most recent changes from #477 now. Sorry for the lack of feedback recently, I've simply not had much time to spend on debugging this!

[medranocalvo]

@tazjin, did it solve the issues?

[tazjin]

@medranocalvo Hey! It seems to have solved most causes of this. Since installing your latest patches (which I did on September 2nd) I have seen this issue only once or twice, and that was in situations like having xrandr still configured to emit output on a display that is no longer connected.

Because of those edge-cases where it occurred again I presume there are actually multiple different causes for the symptom, and you solved the primary one! It's difficult to be 100% sure though.

[medranocalvo]

That's good to hear. Please continue reporting other issues whenever you find a pattern to them. I'll close this issue once there's a new release.

[medranocalvo]

This fix is included in the new 0.20 release. Thank you for the report and follow-ups.

[etu]

Hello, I'm here with the sad news.

I've seen this issue on a regular basis, mostly with Slack desktop but also with Chromium. But only when I have more than one display (I think).

I was just at a conference room and ran autorandr common to mirror my screens in the same resolution and Slack showed up on top of almost all workspaces.

This is my exwm config: https://github.com/etu/nixconfig/blob/master/overlays/local/modules/my-exwm.nix#L9-L65

This is the rest of my emacs config: https://github.com/etu/nixconfig/blob/master/overlays/local/modules/emacs-files/base.el

I'm running latest git master of exwm and xelb from this overlay: https://github.com/adisbladis/exwm-overlay

[ch11ng]

@etu There is indeed an issue with monitor mirroring. I've pushed bd99d8cf7fe3be24d370f8a99332f33c4106f510 to fix this.

[etu]

@ch11ng Thanks, I've just tried this on a beamer with monitor mirroring and had Slack desktop running and it didn't behave badly. So this latest update works great in that case :-)