Race during window setup when creating windows for embedding
Steps to reproduce
- spawn urxvt in the awesome window manager
read xid < <(tabbed -d) zathura -e "$xid" 1.pdf & zathura -e "$xid" 2.pdf
zathura window that is meant to be displayed inside
tabbed is never rendered (displays black)
- tabbed 0.6
- zathura 0.3.8-0.4.0
- xorg-server 1.19.5
- Gentoo with 4.14.52 kernel
- xf86-video-intel 2.99.917_p20180214
- C(XX)FLAGS: --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=haswell -march=x86-64
- Gtk+ 3.22.30
I have been trying to track the source of this bug for a while now;
zathura bug report: In short they say they shouldn't be executed with
DESKTOP_STARTUP_IDset (freedesktop specification).
urxvt explained why this is not their issue (since I noticed it was working with
- awesome's psychon did a lot of hard work to track this bug down, leading to issues in Gtk - described in the linked thread. Specifically he writes:
The root of the bug is that GTK creates its client window directly inside the embedder. Thus, there is a race between GTK setting up its window and at the same time the embedder starting to work with the window.
This precise bug happened when tabbed managed to map the window before GTK asked the X11 server "please tell me when my window is mapped". Thus, GTK never learnt about this happening."
and points out that this sort of issue might be present elsewhere in GTK.
I welcome you to take a look at all these reports to get more details and form a better opinion about what needs to be done.
Thanks in advance!