bug in compiz and frame extents

[totaam]

Issue migrated from trac ticket # 1279

component: client | priority: major | resolution: upstream | keywords: x11 ubuntu compiz frame extents

2016-08-06 15:50:19: antoine created the issue

---

This is just a tracker ticket for redirecting users to compiz where the bug belongs. Other window managers may have similar bugs.
Their bug tracker [http://bugs.compiz.org/] seems to be broken, so we'll just have to live with the ugly warning until someone fixes the compiz code.

As of r13253, the warning we print looks like this:

Warning: invalid frame extents value '[0, 0, 0, 0, 0, 0, 28, 0]'
 this is probably a bug in 'Compiz'
 using '[0, 0, 28, 0]' instead

What happens: for frame extents synchronization (#919), we send a _NET_REQUEST_FRAME_EXTENTS on the window we create for this purpose. The window is realized but not yet visible. (this is what seems to confuse compiz)
When we query the value of _NET_FRAME_EXTENTS, we get 8 32-bit values rather than 4.

This can easily be tested using this GTK test application: [/browser/xpra/trunk/src/tests/xpra/x11/get_frame_extents.py].
It prints the window's XID, so you can also use xprop to verify that the bug is not in the xpra X11 glue code.

[totaam]

2016-08-06 15:51:26: antoine changed status from new to closed

[totaam]

2016-08-06 15:51:26: antoine set resolution to upstream

[totaam]

2016-08-06 15:51:26: antoine commented

---

this is not a bug in xpra.

[totaam]

2016-08-09 15:43:26: antoine commented

---

FWIW: had a look at the compiz code and it looks fine, yet even xprop reports the wrong values..

[totaam]

2016-10-30 05:07:11: antoine commented

---

Try harder to avoid errors when we get the wrong values: r14331. (backport in r14332)

[totaam]

2018-09-26 13:08:03: antoine commented

---

Warning message fix: r20535.