xfwm4 gets confused if a non-override-redirect window is made override-redirect and quickly mapped
In Qubes OS, all third-party applications run in virtual machines with no access to the display. These VMs use a custom Qubes-specific GUI protocol to communicate with a trusted GUI daemon, which draws windows on their behalf. The GUI daemon works with a patched window manager to enforce various restrictions on these windows, such as prefixing their titles and classes with the VM name.
One of the restrictions enforced by the GUI daemon is that an override-redirect window must either be entirely off-screen or entirely on-screen. It cannot be partially off-screen, as that would allow it to hide the unspoofable colored border and overlap the trusted menu bar at the top of the screen. This is enforced in two ways: first, the GUI only creates override-redirect windows with safe positions, and second, any override-redirect window that acquires an unsafe position is moved back to a safe one.
Prior to Qubes Security Bulletin 073 being issued, only the first protection was in place. It turns out that this protection could be bypassed by creating a non-override-redirect window with an unsafe position, and then making it override-redirect immediately before mapping it. The GUI daemon would move it to a safe position before mapping the window, but XFWM4 would then sometimes move it back to the original (unsafe) position. I believe this is an XFWM4 bug.
The output of xfwm4 --version
follows.
This is xfwm4 version 4.14.2 (revision bb38fd909) for Xfce 4.14
Released under the terms of the GNU General Public License.
Compiled against GTK+-3.24.20, using GTK+-3.24.28.
Build configuration and supported features:
- Startup notification support: Yes
- XSync support: Yes
- Render support: Yes
- Xrandr support: Yes
- Xpresent support: Yes
- Embedded compositor: Yes
- Epoxy support: Yes
- KDE systray proxy (deprecated): No