019ae6d06c
This fixes race conditions, for example when i3bar gets reconfigured after the available outputs change. In that specific case, i3bar sends a ConfigureWindow request (seeb5693d6fb3/i3bar/src/xcb.c (L376)) which normally is turned into a ConfigureRequest that i3 largely ignores, only the dock client’s height is considered (seeb5693d6fb3/src/handlers.c (L390)). Turning ConfigureWindow into ConfigureRequest is only done when the SubstructureRedirect event mask is set, and because we temporarily removed _all_ events from our mask, the ConfigureWindow request went through unmodified. This in turn lead to the i3bar client window (not its decoration frame) being positioned at e.g. y=1304, whereas dock client windows should always end up at x=0 y=0 within their decoration frame. The result of the i3bar client window being out of the visible space was either a black i3bar or graphics corruption. This also fixes issue #1904, I think. I couldn’t reproduce issue #1904 specifically, but when i3bar is in the misconfigured state, it will receive a VisibilityNotify event, telling i3bar that it is obscured. This would explain why i3bar sent a SIGSTOP in issue #1904. fixes #1904
