While debugging a port of the classic xwininfo command from the libX11 to libxcb API's, I noted that the class info shown for some java windows contained bogus extra characters on the end. For instance, while the Xlib version of xwinfo showed: 0x5400010 "FocusProxy": ("Focus-Proxy-Window" "FocusProxy") 1x1+-1+-1 +1313+1 the xcb version showed: 0x5400010 "FocusProxy": ("Focus-Proxy-Window" "FocusProxyFra1") 1x1+-1+-1 +1313+1 Digging into this, I discovered that Xlib was hiding a bug in Java. Xlib always adds a trailing '\0' byte to property strings, while xcb does not. This exposes that Java is not including the trailing '\0' when setting the WM_CLASS string - from XBaseWindow.java: void setWMClass(String[] cl) { if (cl.length != 2) { throw new IllegalArgumentException("WM_CLASS_NAME consists of exactly two strings"); } XToolkit.awtLock(); try { XAtom xa = XAtom.get(XAtom.XA_WM_CLASS); xa.setProperty8(getWindow(), cl[0] + '\0' + cl[1]); } finally { XToolkit.awtUnlock(); } } But the ICCCM specifies that unlike most window properties, which are not null terminated, the WM_CLASS is a special case that must be null terminated: Note that WM_CLASS strings are null-terminated and, thus, differ from the general conventions that STRING properties are null-separated. This inconsistency is necessary for backwards compatibility. (BTW, the error message for the IllegalArgumentException seems to have an extra "_NAME" on the end of the property name.)
|