]> git.sur5r.net Git - i3/i3/commit
Bugfix: don’t remove SubstructureRedirect event mask temporarily
authorMichael Stapelberg <michael@stapelberg.de>
Tue, 22 Dec 2015 21:33:37 +0000 (22:33 +0100)
committerMichael Stapelberg <michael@stapelberg.de>
Tue, 22 Dec 2015 21:33:37 +0000 (22:33 +0100)
commit019ae6d06cc7a8df5b34f60c2685955ba3bc3c48
tree5accff434a33e36cb3b935d1e1ac2547230b9d63
parentb5693d6fb33ad29337e4187a2db4a2618ea8fb4c
Bugfix: don’t remove SubstructureRedirect event mask temporarily

This fixes race conditions, for example when i3bar gets reconfigured
after the available outputs change. In that specific case, i3bar sends a
ConfigureWindow request (see
https://github.com/i3/i3/blob/b5693d6fb33ad29337e4187a2db4a2618ea8fb4c/i3bar/src/xcb.c#L376)
which normally is turned into a ConfigureRequest that i3 largely
ignores, only the dock client’s height is considered (see
https://github.com/i3/i3/blob/b5693d6fb33ad29337e4187a2db4a2618ea8fb4c/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
src/x.c