New windows sometimes do not appear until another X event occurs

[donaldcallen]

I am running bspwm 0.9.7-1 on an up-to-date Arch Linux system. Occasionally, I do something that should create a new window, e.g., right-click->window->new-window in rox-filer, or run a window-creating command in my own personal financial manager. Sometimes, not always, the window will not appear until I press a key or click the mouse. The recent bspwm update had no effect on this problem; I had seen it with the previous version as well. I should also mention that I run Arch and bspwm/sxhkd/yabar on multiple machines (desktops, laptops (Thinkpads)) and I've seen the problem on all of them, so not specific to particular display hardware.

[ikselven]

I'm seeing this, too, though I noticed that it's only affecting applications based on GTK. Some situations when this happens:

• opening the Firefox profile manager with firefox -p (the same goes for Thunderbird)
• opening the open/save dialog (GtkFileChooserDialog) in various GTK applications, e.g. Meld or Mousepad

bspwm version: 0.9.7 (as far as I remember, I've seen this happen on 0.9.5 as well) distro: Arch Linux

[donaldcallen]

On Wed, 27 Feb 2019 at 15:38, Felix Glaser notifications@github.com wrote:

I'm seeing this, too, though I noticed that it's only affecting applications based on GTK. Some situations when this happens:

• opening the Firefox profile manager with firefox -p (the same goes for Thunderbird)
• opening the open/save dialog (GtkFileChooserDialog) in various GTK applications, e.g. Meld or Mousepad

bspwm version: 0.9.7 (as far as I remember, I've seen this happen on 0.9.5 as well) distro: Arch Linux

Interesting observation re gtk. I don't know about rox-filer, but my finance application uses gtk3.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/baskerville/bspwm/issues/935#issuecomment-468020783, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzjJ3Ww61PVEqMdNRnom2NN62htS55Uks5vRuytgaJpZM4bTZc4 .

[ikselven]

Since I noticed it yesterday: launching Mousepad (XFCE's text editor) is sometimes affected by this, too.

[donaldcallen]

On Wed, 6 Mar 2019 at 05:49, Felix Glaser notifications@github.com wrote:

Since I noticed it yesterday: launching Mousepad (XFCE's text editor) is sometimes affected by this, too.

Despite the fact that I generally prefer bspwm to any other tiling window manager, this is a serious enough issue for me that I've switch to xmonad, which has no such problem, until this bug is fixed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/baskerville/bspwm/issues/935#issuecomment-470061329, or mute the thread https://github.com/notifications/unsubscribe-auth/AEzjJ7w1IaFwHebFq-c8g60AR_jXwZwyks5vT50ngaJpZM4bTZc4 .

[dannycolin]

bspwm version: 0.9.7 (as far as I remember, I've seen this happen on 0.9.5 as well)

I can confirm. The regression happened between 0.9.2 and 0.9.5.

[baskerville]

It would be great to find a way to consistently reproduce the problem…

[dannycolin]

@baskerville I know nothing about X debugging but I'm willing to help if you can provide some tips.

[baskerville]

One thing you could do is to record the X events with xtrace.

I'm assuming that src/bspwm.c blocks on the select call, and fails to realize that there is something to read on dpy_fd… But I don't see how it might happen.

[donaldcallen]

After more than a year, I am giving bspwm another try (because, overall, I like it very much), hoping that this problem might have been found and fixed. It hasn't. I do understand that without a reproducible example (and it seems to be a race condition, probabilistic, so the nature of the beast is that it is not reliably reproducible), this is a tough one to find.

I did want to provide one bit of additional information -- I tried to start a download with Firefox of the kind that should have popped up a "where to put the file and what to name it" dialog and the dialog did not appear -- until I moved the mouse. I repeated this again several times and the problem did not recur. This is on an up-to-date Arch Linux system.

[ortango]

@baskerville i have a few xtrace dumps of this issue. i wonder if there is a prefered "format"? the xtrace logs are a bunch of runs of zenity until the issue is triggered, sometimes it takes 30+ runs, sometimes 1 or 2. also, sometimes i kill xtrace before i let that problem window map, sometimes i kill after it maps. so whatever is most helpful i think i can provide.

also, i think it is as you are assuming. when the problem occurs the window remains unmapped and gdb shows bspwm at that select() and waiting. the next event will cause the map request to be processed.

[donaldcallen]

On Sat, 7 Nov 2020 at 12:27, ortango notifications@github.com wrote:

@baskerville https://github.com/baskerville i have a few xtrace dumps of this issue. i wonder if there is a prefered "format"? the xtrace logs are a bunch of runs of zenity until the issue is triggered, sometimes it takes 30+ runs, sometimes 1 or 2. also, sometimes i kill xtrace before i let that problem window map, sometimes i kill after it maps. so whatever is most helpful i think i can provide.

also, i think it is as you are assuming. when the problem occurs the window remains unmapped and gdb shows bspwm at that select() and waiting. the next event will cause the map request to be processed.

Really good work. Hopefully it leads to a fix. bspwm is an excellent window manager, but this is a major flaw.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/baskerville/bspwm/issues/935#issuecomment-723471931, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGOGJZ5WZFHDEH2TEPTMBDSOV7O3ANCNFSM4G2NS44A .

[ortango]

i will just drop an archive of 3 logs here. any questions or requests just ask.

xtrace-logs.tar.gz

[twouters]

I can reproduce this with a clean bspwm install using the following loop:

while true; do sleep 1; zenity --password; done

Just press escape when the password dialog pops up, after a few attempts it won't appear until another event is triggered.

[twouters]

I can reproduce this with a clean bspwm install using the following loop:

while true; do sleep 1; zenity --password; done

Just press escape when the password dialog pops up, after a few attempts it won't appear until another event is triggered.

I was wrong: tried to reproduce it with a clean install (vagrant archlinux image) and can't reproduce there.
I figured that creating a new user, and copying bspwm and sxhkd config files would be "clean enough" but that doesn't seem to be correct.

[emanuele6]

I used

x11trace -D :9 -d :0 -o "dialog$((++i)).log"; echo "$i"

and launched zenity with:

DISPLAY=:9 zenity --password

log - window appears immediately: dialog18.log - 1649 lines log - window doesn't appear until mouse click: dialog19.log - 5015 lines

[Rational-Curiosity]

This patch works on my computer: Ubuntu 20.04.1 commit: e22d0fad23e0e85b401be69f2360a1c3a0767921

diff --git a/src/bspwm.c b/src/bspwm.c
index 9c6be76..18ccdda 100644
--- a/src/bspwm.c
+++ b/src/bspwm.c
@@ -36,6 +36,7 @@
 #include <stdbool.h>
 #include <string.h>
 #include <xcb/xinerama.h>
+#include <xcb/xcb_aux.h>
 #include "types.h"
 #include "desktop.h"
 #include "monitor.h"
@@ -204,6 +205,7 @@ int main(int argc, char *argv[])
        while (running) {

                xcb_flush(dpy);
+               xcb_grab_server(dpy);

                FD_ZERO(&descriptors);
                FD_SET(sock_fd, &descriptors);
@@ -247,14 +249,14 @@ int main(int argc, char *argv[])
                                }
                        }

-                       if (FD_ISSET(dpy_fd, &descriptors)) {
-                               while ((event = xcb_poll_for_event(dpy)) != NULL) {
-                                       handle_event(event);
-                                       free(event);
-                               }
+                       xcb_aux_sync(dpy);
+                       while ((event = xcb_poll_for_event(dpy)) != NULL) {
+                               handle_event(event);
+                               free(event);
                        }

                }
+               xcb_ungrab_server(dpy);

                if (!check_connection(dpy)) {
                        running = false;

[emanuele6]

@Curiosidad-Racional as far as i can tell, that patch fixed the issue. But now, when I try to move floating windows with the move pointer action (default: mod4 + button1), they are only moved after releasing the mouse button (same for the other pointer actions).

[Rational-Curiosity]

Apply this patch to the same commit: e22d0fad23e0e85b401be69f2360a1c3a0767921 ignoring last patch. In my case issue fixed without breaking floating window movement.

diff --git a/src/bspwm.c b/src/bspwm.c
index 9c6be76..8b9b5d1 100644
--- a/src/bspwm.c
+++ b/src/bspwm.c
@@ -36,6 +36,7 @@
 #include <stdbool.h>
 #include <string.h>
 #include <xcb/xinerama.h>
+#include <xcb/xcb_aux.h>
 #include "types.h"
 #include "desktop.h"
 #include "monitor.h"
@@ -248,6 +249,7 @@ int main(int argc, char *argv[])
                        }

                        if (FD_ISSET(dpy_fd, &descriptors)) {
+                               xcb_aux_sync(dpy);
                                while ((event = xcb_poll_for_event(dpy)) != NULL) {
                                        handle_event(event);
                                        free(event);

Thanks @emanuele6.

[twouters]

Latest patch works for me :man_shrugging: